I wrote:
> 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.
Okay I was quite confused. Jeremy has spent a lot of time today trying to
help remedy this - with limited success I'm afraid.
Basic point: actions that have a happens-before relationship need not happen
in that order. They are allowed to be reordered provided that the reordering
is not visible to anything that has a happens-after relationship with the
reordered actions.
What I'm getting stuck on is a set of rules for reasoning about whether
certain reorderings are allowed, such that I can reason about lock-free
algorithm using volatiles.
Getting back to Doron's original issue about default initialization, the key
point here is that the behaviour is as-if every object that would be created
in a program was created with its default initialized values prior to the
program starting. Hence every action in the program must happen-after that
initialization. So given:
class Y { int y; }
then this code:
x = 1;
new Y();
might appear to be the same as this:
x = 1;
y = 0;
but it is not because "y=0" effectively happened before the program started.
The way this is currently described is not clear.
David Holmes
-------------------------------
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