> Jeremy Manson wrote:
> > That depends on where one imagines that the write of the default value
> > actually occurs. We think of it as an "outside the thread in which is was
> > constructed" action, because if we had:
> >
> > Thread 1:
> > x = 1;
> > y = default;
> >
> > Thread 2:
> > r1 = y
> > r2 = x
> >
> > And then we said that there was a happens-before edge from the
> > write of the
> > default value to the read of y, then the read of x would have to see 1.
> > This is not our intent.
>
> I don't follow. Just because there is a happens-before edge between y =
> default and r1 = y it doesn't mean there is a happens-before edge between x
> = 1 and y = default, or between r1 = y and r2 = x. The order of statements
> in both or either threads could be switched around.
If x and y are actions of the same thread and x comes before y in program
order, then x happens-before y. There would therefore be a transitive
happens-before edge from x = 1 to r1 = y. This is how volatile variables
work (with respect to ensuring that one thread communicates non-volatile
values with another).
If initialization worked this way, implementations would not be free to
reorder these statements. That's a very good reason why it does not work
this way.
This property of intra-thread actions is in the three-pager, where we note
that happens-before is the union of synchronization order and program order.
It has also been in every draft of the spec so far.
The whole issue of the intra-thread happens-before edge has caused some
confusion. The model does not imply that because there is a happens-before
edge between two actions, they cannot occur out of order. Here's another
example, where the reordering is allowed:
Thread 1
r1 = x;
y = 1;
Thread 2
r2 = y
x = 1;
Result: r1 = r2 = 1
Note that r1 = x happens-before y = 1, and r2 = y happens-before x = 1.
It is legal under the model for the read of y to see 1 or 0. It is also
legal under the model for the read of x to see 1 or 0. Therefore, even
though there is a happens-before relationship between the actions of the
threads, the model can produce a legal result regardless of the order of
execution.
Jeremy
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:04 EDT