[concurrency-interest] synchronized on construction
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
More information about the Concurrency-interest