Bill Pugh wrote:
> 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.
Can the two assignments be re-ordered? If so it would be possible to write
to the final then do the store-store barrier and hence have no impact on the
volatile write per-se.
Further, even with a store-store barrier at the end of the constructor that
still wouldn't help with the situation where the constructor was inlined.
Given
> class C {
> volatile Object v;
> final Object f;
> C(Object a, Object b) {
> v = a;
> f = b;
> }
> }
Globals.globalC = new C();
could expand to something like:
globalC = allocZeroedMem(sizeof(C));
globalC->v = ...
globalC->f = ...
storestoreBarrier;
For this to work correctly it is the shared *reference* globalC that must be
correctly synchronized: globalC must be final, volatile, or else set and
read whilst holding a monitor.
But in that case the "safety" of immutable objects is once again dependent
on correct synchronisation of the reference to the immutable object.
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:02 EDT