Incidentally, I am getting a lot of garbage in your messages, in addition
to the HTML. Is this a MS mail reader thing?
> What I meant was this:
>
> boolean step1 =3D false;
> volatile boolean step2 =3D step3 =3D false;
>
> Thread 1:
> {
> step1 = true;
> step2 = true;
> step3 = true;
> }
> Thread 2:
> {
> r2 = step2;
> r3 = step3;
>
> if(r3 == true)
> {
> r1 = step1;
> // at this point, r1 and r3 are always true,
> // but r2 may not be true. Even though step2 is a volatile
> // that's been assigned before step3.
> }
> }
>
This makes sense to me. In SC, you can have the following behavior (using
1 and 0 for true and false):
PC Thread 1 Thread 2
1 r2 = step2; (r1 = 0, r2 = 0, r3 = 0)
2 step1 = 1; (r1 = 0, r2 = 0, r3 = 0)
3 step2 = 1; (r1 = 0, r2 = 0, r3 = 0)
4 step3 = 1; (r1 = 0, r2 = 0, r3 = 0)
5 r3 = step3; (r1 = 0, r2 = 0, r3 = 1)
6 if(r3 == 1) (r1 = 0, r2 = 0, r3 = 1)
7 r1 = step1; (r1 = 1, r2 = 0, r3 = 1)
That is a perfectly legitimate ordering.
> Maybe SC is too expensive to implement, but I think we should at least
> require a volatile write (release) to commit all previous volatile
> writes together with the previous normal writes so that a volatile flag
> doesn't have a less relaxed semantics than normal flag in this regard.
I think I see your difficulty. The fact that we don't include volatile
writes in the previous_t sets may be throwing you off a little. The
simple way to understand volatiles (their "simple semantics", as we put it
in the paper) is that a volatile can have exactly one value at any time.
We fudged that a little for architectures that don't support atomic
instructions, but we can ignore that for the purpose of this discussion.
If we look at the model, we see two successive volatile writes become:
1: initVolatileWrite a = 1;
2: performVolatileWrite a = 1;
3: initVolatileWrite b = 1;
4: performVolatileWrite b = 1;
The variable a and the variable b each has a value associated with it,
what we call its volatileValue. The performVolatileWrite in line 2 sets
volatileValue(a) to be 1. All other values that have ever been associated
with a are now gone. The performVolatileWrite(b) in line 4 now sets
volatileValue(b) to be 1. All other values that have ever been associated
with b are now gone.
Let's say another thread performs a read of b followed by a read of a,
after this write to b has happened. It will see the volatileValue(b),
which is 1, followed by the volatileValue(a), which is also 1. It cannot
see any older value for a. Volatiles thus actually have stronger
semantics than normals, which can see any of a set of possible values.
Does that assuage your difficulty? Or did I miss the point of your
question?
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT