> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Thomas Wang
> Sent: Wednesday, March 17, 2004 5:01 PM
> To: javamemorymodel@cs.umd.edu
> Cc: wang@cup.hp.com
> Subject: JavaMemoryModel: Question about the semantics of volatile
>
>
> > Initially, x = y = v = 0.
> > v is a volatile variable.
> >
> > Thread 1:
> > r1 = x
> > v = 0
> > r2 = v
> > y = 1
> >
> > Thread 2:
> > r3 = y
> > v = 0
> > r4 = v
> > x = 1
> >
> > Is the behavior r1 == r3 == 1 possible?
>
> I think r1 == r3 == 1 being impossible is more intuitive.
I think it is better to not rely on intuition when writing multithreaded
code on a machine that is not sequentially consistent.
For example, if we changed v to another variable on thread 2, the behavior
would be possible on both interpretations, which some may construe to be
non-intuitive. That is, consider:
Thread 1:
r1=x
v=0
r2=v
y=1
Thread 2:
r3=y
v2=0
r4=v2
x=1
Then r1==r3==1 becomes possible with the strong and weak interpretations.
In other words, regardless of the interpretation, one cannot consider
volatiles as a fence for a single thread. Given that we certainly don't want
anyone writing code such as the above modification, I don't know that we
want to encourage anyone writing the original code that Bill gave.
>
> I also believe volatile variables preventing compile time
> code motion is
> a good idea, for the same reason.
Again, it is a myth that volatile variables prevent compile time code
motion. They prevent it some of the time but not all of the time. To figure
out when they do or do not prevent it, we have to reason about the
happens-before relation.
To reason with the weaker relation, we have to know about program order and
we have to know which synchronization read returned the value from which
write. To reason with the stronger relation, we need to additionally know
about a total ordering on all conflicting synchronization writes. Thus, the
stronger semantics are marginally harder to explain.
I fear that allowing the stronger semantics will further foster the illusion
that synchronization is somehow a fence or memory barrier. Further, for
software DSM's like Treadmarks, the stronger semantics could require keeping
track of concurrent writers, which can be done, but is harder.
On balance, this may not be a huge deal, but it is better to make an
informed decision.
Sarita
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:00 EDT