Re: JavaMemoryModel: Race-proof mutable objects and synchronized constructors

From: Joseph Bowbeer (
Date: Sat Dec 02 2000 - 02:00:10 EST

Do you have a code sample?

Are you just creating a thread or are you starting it, too?

----- Original Message -----
From: "Allen Holub" <>
To: "Bill Pugh" <>
Cc: <>
Sent: Friday, December 01, 2000 6:49 PM
Subject: Re: JavaMemoryModel: Race-proof mutable objects and
synchronized constructors


One situation I have wrestled with is that of an object that creates a
thread (implemented as an inner class) from within the constructor. The
created (inner-class) object cannot access the creating (outer-class)
object reliably, since there's no memory barrier or synchronization.
usually solved this problem by synchronizing the constructor [with a
synchronized(this)] and then having the inner-class constructor
using synchronized(Outer.this). The problem with this strategy is that
code that assigns a value to a field that's initialized in the
(which can take an initial value from the outer-class object) is not
included in the synchronized block. On the other hand, it's quite
how it works---the created thread is effectively suspended until the
creating constructor exits the synchronized block. Your second proposal
seems to solve this access-by-initializer problem, but synchronizing the
constructor seems like a more intuitive solution. Perhaps the best
is to support both mechanisms.


>Say you want to design a class Foo that is designed to work correctly,
>even if references to Foo objects are passed between threads via a data
>race (perhaps maliciously so). Strings are one example of a class we
>to have be race-proof.
>For immutable classes, we have a solution: use final fields. But what
>about for mutable classes?
>The standard approach in such cases would be to simply synchronize all
>the methods of the class, but to not synchronize the constructor.
>Syntactically, it is illegal to declare a constructor as synchronized.
>could fake it using a synchronized block inside the constructor, but
>never seen code that does so.
>Unfortunately, to really make the class race-proof, you need to have
>constructor be synchronized. Without a synchronized constructor, there
>nothing that forces the processor that initializes the object to send
>initializing writes from its cache out to main memory.
>The JLS states (Section 8.8.3):
>"Unlike methods, a constructor cannot be abstract, static, final,
>or synchronized.... There is no practical need for a constructor to be
>synchronized, because it would lock the object under construction,
>is normally not made available to other threads until all constructors
>the object have completed their work. "
>Unfortunately, this is wrong (and has led to some confusion). While
>is no practical need in constructors for the mutual exclusion semantics
>synchronization, synchronization also has important visibility
>that are relevant for constructors.
>I see two possible solutions:
>* Say that in order to bullet-proof the class, you need to use
> in constructors. You could do this through a synchronized block, but
> could
> also change the language to allow synchronized constructors.
> -- or --
>* Give constructors special visibility semantics: when a thread
> on an object, it sees all writes that were visible to the
> thread
> at the time the object's constructor terminated. In other words, all
> constructors have the visibility semantics of being synchronized,
> without the
> mutual exclusion semantics of being synchronized. Assuming that you
> don't make
> objects visible to other threads until after they are constructed,
this is
> essentially the same as synchronizing all constructors.
>Given these choices, I recommend the second option. Although either
>allow for the creation of race-proof classes, the first option would
>that most/all existing synchronized classed would be broken, and I
>it would be very hard to get most programmers to understand why and
>constructors need to be synchronized. I don't think choosing the second
>option would require more memory barriers; for a number of reasons, we
>probably already need a memory barrier at the end of each constructor
>processors with weak memory models.
> Bill
>JavaMemoryModel mailing list -

JavaMemoryModel mailing list -

JavaMemoryModel mailing list -

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