Bill Pugh wrote:
> As you know, we had decided to relax volatile variables so that they
> weren't quite sequentially consistent.
We had? Can you restate (in simple terms) in what way volatiles *are*
> TEMPORAL LOOPS AND OTHER PARADOXES
> Thread 1:
> x = 1
> Thread 2:
> r1 = z
> r2 = x
> y = r2
> Thread 3:
> r3 = y
> z = r3
> The question is: can this program result in r1=1?
> We need for this result to be possible. A compiler could easily
> decide to reorder the read of z in thread 2 to the last action in
> thread 2, and then an a sequentially consistent execution would allow
> r1=1. Under our previous semantics however, it could not. For that to
> happen, we would need to perform an initWrite of y=1 in thread 2
> before reading z. But at that point, we can't guarantee that a 1 will
> in fact be written to y. We can't use a guaranteed read because
> guaranteed reads are restricted to see properly synchronized reads.
I don't quite see the problem in terms of the semantics of the model. But
given the example uses absolutely no sync, I can't see anything to stop the
reordering within thread 3 to do the read of z last.
> EXPECTED DATE FOR PUBLIC REVIEW
> Jeremy and I are focused on this now, and we hope to have JSR ready
> for public review by the end of July.
You mean community review - right?
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:40 EDT