Sarita Adve wrote:
> Consider:
>
> Thread 1:
> A
> Initially all variables are 0
> Thread 1
> A = 1
> Volatile1 = 2
> tmp1 = Volatile2
> B = 1
>
> Thread 2
> while (B != 1) {;}
> Volatile3 = 3
> tmp2 = Volatile4
> tmp3 = A
>
> Treating a volatile as a barrier with respect to normal
> accesses (either one way or two way) means that tmp3 should be 1. This is
not
> enforced by Bill's proposal so far.
The reason being that the two threads use different volatile variables. I
don't think the above should be guaranteed to work - it is like the current
global behaviour of monitors and that is a behaviour which is being changed
in the new JMM.
I don't see any problem with allowing removal of thread-local volatiles. Any
non-thread-local volatiles would then exhibit the one-way or two-way barrier
behaviour (with acquire/release visibility semantics) as is being discussed.
> The above example shows that treating volatiles as barriers
> means that you are allowing communication between threads through
> non-volatile/non-synch variables (B, in the above example). As Bill said,
it isn't
> clear to me that this is good programming practice.
Not when different volatiles are used. When the same volatile is used then
one of the main goals of the JMM revision is to allow communication between
threads using non-sync, non-volatile fields when that communication is
"mediated" (for want of a better term) by access to a shared volatile. This
is the essence of making Dekkers algorithm work and for making
double-checked locking work.
I don't think your definition of volatile is really that different from what
is being discussed. The focus on one-way and two-way barriers was really
just looking at the ordering properties of volatiles - not the visibility
properties, which I for one, am already taking for granted. The simple
difference, I think (and of course this is not a formal description), is
that before reasoning about the behaviour volatiles will induce, you have to
ensure that thread-local volatiles are removed.
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:33 EDT