RE: JavaMemoryModel: Tiger beta1 ConcurrentHashMap bug?

From: David Holmes (
Date: Thu Apr 08 2004 - 19:50:44 EDT

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.
> 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 = ...

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 -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT