At 7:18 AM -0400 10/27/99, Doug Lea wrote:
> > Now there is no one right answer, because before Java, no one tried
> > to define the semantics of volatile. And right now, nobody uses
> > volatile much in Java.
>Well, the current JLS ch17 account of volatile is among the least
>ambiguous parts of the spec, and some people (including me) do have
>code relying on its stated properties. (For example my work-stealing
>dequeue code in my fork/join framework in util.concurrent.) However,
>assuming I understand it correctly, all of this code would continue to
>work under your model (see below).
Yes. The previous rules essentially said that reads and writes of all
volatile variables are sequentially consistent. I strengthen that by
giving rules about the possible reordering of volatile and
non-volatile memory actions.
>In any case, I think the choices in specification amount to:
> read write
>1. single RB before WB after
>2. monitor-style RB before, WB after RB before, WB after
>3. double RB before, RB after WB before, WB after
>The current spec seems to allow choice (1).
It isn't as simple as that. For example, if you read a volatile
variable, then write a different volatile variable, using (1) would
But this would allow another thread to see the write of y before the
read of x, which must not be allowed to happen. In particular, if x
and y are volatile and initially 0, then if I run:
Thread 1 Thread 2
a = x b = y
y = 1 x = 1
this code must not be able to produce a = b = 1. But using (1), it could.
Using my proposed semantics, on the IA64, it _almost_ suffices
implement the reads with ld.acq instructions, and the writes with
st.rl instructions. The only case not handled by that is that a
volatile write following by a volatile read could be reordered.
For something like the double-check idiom, a good compiler will
combine a lot of the memory barriers. But still, using volatiles for
the double check idiom is a bit of overkill.
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:21 EDT