[concurrency-interest] synchronized on construction

Thomas Hawtin tackline at tackline.plus.com
Wed May 24 06:31:24 EDT 2006


Jeremy Manson wrote:
> Jason Mehrens wrote:
>> Browsing over the java.util.Vector class I noticed that in the constructors, 
>> the initial writes to the internal data members (non-final and non-volatile) 
>> are not performed under a synchronized block.   The same is true for when a 

Under the new JMM would a synchronised block in the constructor 
guarantee to fix the problem? Does the racy write of the Vector 
reference, outside of the synchronised block, necessarily come after the 
block itself. Could it technically be moved up before the lock is 
acquired? Or am I misinterpreting something?

>> Vector is deserialized.  Where does happens-before edge occur so that other 
>> threads don't see uninitialized values of the internals?  The only happens 
>> before-edges I can think of are during handoff between threads or on the 
>> call to Thread.start().  Is how this class conforms to the JMM or is 
>> something else going on?
>>
> 
> Well, bear in mind that only one thread has access to instances of these 
> classes during construction.  JMM problems only come up here if you pass 
> a reference to the object to another thread via a data race.  These 
> classes are not designed to work correctly if you do that - only the 
> immutable ones, like String, really are.
> 
> If you are using this class, it is therefore imperative to provide 
> proper synchronization during a handoff.

Bug 6379897 deals with the thread safety of Random's seed when 
constructed lazily in Collections. It's interested to see that the fix 
for that attempts to make the use of seed thread-safe, rather than 
construct the Random safely in Collections. Presumably the details of 
that fix (setting of the seed value) require that my first paragraph is 
wrong...

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6379897

Tom Hawtin


More information about the Concurrency-interest mailing list