>I cannot determine why the assignment to volatile 'count' will ensure
>visibility (to reader threads which do not acquire a lock) of the
>preceeding change to e.value (the 'value' field is non-volatile).
>Although "e.value = value" happens before "count = c" in the code, the
>compiler could presumably reorder the assignment "e.value = value"
>after "count = c", since it is clear that 'e' cannot be null.
Within the thread that does this, as you say, "e.value = value" happens
before "count = c".
Another thread reads count, and then looks at e.value. In that thread, the
read of c happens before the read of e.value.
Between the two threads, the assignment of count = c in the first thread
happens before the read of count in the second thread. Since happens before
is transitive, this means that there is a total order over these
operations. The compiler can do what it likes with optimsation, provided
what it does does not conflict with inferences that can be made from this
ordering. In otherwords, the result has to be what you'd expect given the
happens before rules.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:53 EDT