> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of David Holmes
> Sent: Thursday, April 08, 2004 6:54 PM
> To: jmm
> Subject: RE: JavaMemoryModel: Use-case for strong volatile
> interpretation
>
>
> > Sarita Adve wrote:
> >
> > Still, this is a use case involving a program with
> deliberate data races.
> > Our underlying philosophy throughout has been to not give any
> > guarantees to
> > such programs except for the purposes of safety/security.
>
> I may be misunderstanding what you are saying here, but the
> use of volatiles
> in lock-free algorithms is intended to make such algorithms correctly
> synchronized. Hence the issue of what guarantees you have when using
> volatiles is very important.
>
Sure. Bill was talking about a use-case that has data races (i.e., it is
incorrectly synchronized) according to both semantics (even after inserting
the volatiles as described in his message). The "stronger" semantics under
consideration give some more guarantees than the weaker semantics in that
case. But again, the program has a data race. To make that program
data-race-free (or correctly synchronized), more variables will need to be
made volatile under both semantics. Moreover, the same variables need be
made volatile under both semantics. In other words, any program that is
data-race-free under the stronger semantics is also data-race-free under the
weaker semantics.
For example:
Initially, A=B=V=0, V is volatile
Thread 1
A=1
V=1
r1=V
B=1
Thread 2
r2=B
V=1
r3=V
r4=A
The above program has a data race under both semantics. According to the
strong semantics, some SC executions will have a data race on A while the
others will have a data race on B. However, no SC execution has a data race
on both A and B (since one of the two writes in V occurs first and is
ordered before the other thread's read of V). So the strong semantics will
prohibit the outcome r2=1, r4=0.
According to the weak semantics, some SC executions will have a data race on
A, some will have a data race on B, and some will have a data race on both A
and B (in the case where each thread's read of V returns the value from its
own write of V). So the weak semantics allows the outcome r2=1, r4=0.
To prohibit the outcome under the weak semantics, we have to make both A and
B volatile, it is insufficient to make just V volatile. Now making both A
and B volatile makes the program data-race-free (or correctly synchronized)
under both strong and weak semantics. There is no other way to make this
program with only this set of accesses correctly synchronized under either
semantics.
So again, in Bill's use-case, there is a data race according to both
semantics. To make the program correctly synchronized requires making more
variables volatile, and this makes it correctly synchronized for both
semantics. In fact, any program correctly synchronized for strong semantics
is also correctly synchronized for weak semantics and will see the same
behaviors for both semantics. Our question is about programs that aren't
correctly synchronized.
Please let me know if it is still unclear.
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:02 EDT