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

From: Joshua Bloch (Joshua.Bloch@Eng.Sun.COM)
Date: Sat Dec 02 2000 - 01:32:23 EST


   Assuming the constructor is "solid" (i.e., it doesn't leak references), I
think the mutual exclusion isn't necessary, as the attacker could not
"publish" (or even obtain) a reference until the construction was complete.

   I favor option 2, as it requires a truly compelling need to change the
language. Much better to do a wee bit more work under the covers.

   One thing that saddens me about these approaches is that they require you
to use the object's monitor lock. I often use an internal, private Object for
locking, so as to make objects immune to accidental or intentional "wedging"
by locking:

    synchronized(criticalGlobalResource) {
        sleep(1000000); // The system is wedged!

   I suppose you could have your constructor synchronize on the "private lock
object", but this might leave a "window of vulnerability", if the system
writes any hidden object data after it finishes executing all of the user code
in the constructor. Yecccch.

JavaMemoryModel mailing list -

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