Jan-Willem Maessen wrote:
> Assume v and w are volatile locations, x is a regular location.
>
> v=1 w=1 r1=v r3=w
> r2=w r4=v
>
> Can r1 == r3 == 1, but r2 == r4 == 0? <typo fixed>
> Clearly not, if we believe that volatiles are SC.
It was my understanding that whilst the old JMM defined a total
ordering over all actions on volatiles, the new JMM does not. I'm
probably going to express this imprecisely using the wrong language
but actions on different volatiles are only ordered within a thread,
whilst actions on any one volatile are ordered across threads. The
acquire/release semantics associated with volatile reads/writes apply
to all reads/writes within that thread. Hence in the above there is no
requirement that threads 3 and 4 see the actions of threads 1 and 2 in
the same order. If more shared variables were involved then a total
ordering could be imposed.
> x=8 v=2 r1=v
> v=1 x=9 r2=x
> r3=v
>
> Can r1==r3==1 but r2==9? I remember arguments that this would be a
> bad thing, and therefore we don't want r3=v hb v=2, preventing us
from
> totally ordering actions to a volatile location v in hb. I cannot
> recall why.
If I recall this correctly a volatile read is akin to a lock, and a
volatile write is akin to an unlock. Using that duality and applying
the "roach motel" principle, the write of x=9 in thread 2 is allowed
to move up ahead of the write v=2. Hence we can have:
x=8
v=1
x=9
r1=v
r2=x
r3=v
v=2
and so r1==r3==1 and r2==9.
> One thing has become clear to me is that the total ordering we
obtain
> on locks and volatiles is entirely separate from the notion of
happens
> before.
I do not believe there is a total ordering. Actions on the same lock
are totally ordered; actions on the same volatile are totally ordered.
This is a relaxation of the implied total ordering in the original
JMM.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:49 EDT