Without the rules for final fields, it would be pretty straightforward
that this reordering could
happen.
However, there are additional semantics for final fields.
The standard way to implement final fields would be to put a
store-store barrier at the end of a constructor
in which final fields are assigned.
With a store-store barrier at the end of the constructor, the volatile
field would be
safe (reads of it would never see null).
But while putting store-store barriers at the end of constructors is a
safe and sufficient technique
for implementing final fields, it is stronger than the semantics
requires.
For example, if the field field isn't read anywhere, the store-store
barrier isn't required.
Doug and I have discussed whether it would be possible to change the
semantics
to allow initialization safety for volatile fields of objects passed
via data races. The problem
is that this would require compiler changes (additional store-store
barriers in constructors that
set volatile fields but not final fields). And it is too late in the
game for that.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT