At 3:11 PM -0500 7/10/01, Sarita Adve wrote:
>I would like to point out that based on Bill's proposal so far, volatiles
>cannot be treated as one-way barriers (for non-volatile accesses), leave
>alone as two-way barriers. Let me specify the tradeoffs here a little
>differently from what Bill said in his last message.
>
>I think we have to make a fundamental choice between whether we would like
>programmers to think about the memory model in terms of per-thread
>orderings, or if we are ok with thinking in terms of inter-thread orderings.
I just wanted to point out again that at the moment, I'm trying to
discuss/propose _properties_ of the Java Memory Model, not the
_specification_ of the Java Memory Model.
Even if we have a more complicated formal specification of the
semantics, we can derive per-thread ordering properties that may
prove useful to some programmers and VM implementors.
>But if we choose to use inter-thread spec (Bill's current proposal),
>volatiles can neither be interpreted as one-way nor two-way barriers.
>(Therefore, the programmability argument for two-way barriers seems moot.)
Perhaps a better way to describe a property of acquire/release
volatiles is that they are one-way-always-permeable. In other words,
it is always possible to reorder a normal memory access and a
following volatile read. However, in the other direction, they are
sometimes-permeable: it depends on the details, such as whether any
other thread has written to the volatile variable.
If we follow this logic/terminology, then there isn't much to say
about the strengthened version of volatiles: they are
two-way-sometimes-permeable, which doesn't provide any information.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT