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

From: Doug Lea (
Date: Sat Dec 02 2000 - 09:08:53 EST

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

This problem only occurs when one thread makes a mutable thread-safe
object, but places the ref to it in a place accessible from other,
already-existing threads, without synchronization or any other
technique that would ensure a barrier. I don't think this is a common
error. I can't even recall seeing it, even though I briefly mention
the (rare) need for synch in constructors to deal with it in CPJ book.

I think the main question is whether any basic Java guarantees would
be violated if these errors are allowed to happen (which is a concern
for Strings and other immutable objects). I cannot think of any
offhand. But I wouldn't be too shocked if there exists a stray case
or two in JDK classes. If so, they could just manually synchronize the
constructor body, which they probably should have done anyway.

So, I'm not so sure that this situation requires any special action.
I am not at all opposed to allowing "synchronized" as a modifier for
constructors to make this easier though, as part of JMM JSR. It's a
tiny change, that wouldn't impact any existing code, and is trivial
for compilers and run-times to deal with -- compilers can just
translate it as if constructor body is in synchhronized(this).

JavaMemoryModel mailing list -

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