[concurrency-interest] synchronized constructors

Ruslan Cheremin cheremin at gmail.com
Fri Dec 16 01:43:46 EST 2011

In practice -- yes, it seems to be true. But formally JMM does not
guarantee anything for non-final fields in this context. As far, as I
understand this part of spec, bulletproof guaratee for visibility even
in case data race based publication is done only for final field
itself, of something, reachable from it. I think, it is not a good
thing to piggyback on specific implementation of final fields
semantic, which _may_ use "global" storestore, but not have to.

2011/12/16 Vitaly Davidovich <vitalyd at gmail.com>:
> I think in practice having at least one final field assignment in the
> constructor, irrespective of order, will cause the storestore to be emitted
> after the constructor and before publishing assignment (at least in
> hotspot,  to my knowledge).  Relying on this though is probably not
> prudent.  If you realize that a constructor is just a method (albeit
> special) which can get inlined then you can see how operations can be
> reordered because placement of final field assignment is more obvious
> (people tend to think of constructors as some "atomic" block of code, which
> isn't right IMHO).
> However, I find it hard to believe that even though this behavior is
> implementation specific that Oracle would change this such that order of
> final field assignment matters - this could break massive amounts of code,
> especially as we're getting more and more concurrency in commodity hardware.
> Outside of a purely "academic" discussion here, the main point is avoid data
> racy code :).
> On Dec 15, 2011 6:54 PM, "Yuval Shavit" <yshavit at akiban.com> wrote:
>> From my cursory reading of the JLS and the cookbook that David linked to,
>> I think you're right. The JMM would allow such a reordering, but it sounds
>> like you'd need to actively work on it if you wanted the compiler to honor
>> final field semantics but allow the reordering that would result in the 0
>> being seen.
>> What if you just had a final field that you wrote but didn't use?
>>     final int a;
>>     int b;
>>     MyConstructor() {
>>         a = 1;
>>         b = 2;
>>     }
>> I believe this was the original suggestion to replace the
>> synchronized(this) in the ctor (Natha's email that starts, "One could also
>> add a final field in the class..."). Would that more readily exploit seeing
>> b == 0? And would it be different if the assignments had happened in reverse
>> order (b = 2; a = 1) ?
>> On Thu, Dec 15, 2011 at 6:20 PM, Vitaly Davidovich <vitalyd at gmail.com>
>> wrote:
>>> I think I misinterpreted the question.  Yes if you publish in the middle
>>> of construction then anything goes - final won't help.  If the question is
>>> about unsafe publication after the constructor, then I think in practice it
>>> works because the compiler will issue one storestore after the constructor
>>> and before publishing (regardless of order of final field store in the
>>> constructor ).  In that case, if another thread reads a non-null instance it
>>> should see all writes done inside the constructor.  Presumably though, a
>>> compiler could only issue a storestore after the final field, move the
>>> publishing assignment ahead of the non-final field write, and then a
>>> non-null read on the other thread doesn't guarantee anything about the
>>> non-final field.  I don't think JMM precludes this scenario.
>>> Sorry for the dense text I'm on my phone :).
>>> On Dec 15, 2011 5:53 PM, <dhanji at gmail.com> wrote:
>>>> From a cursory glance, it could happen if the b's value (=a) is sitting
>>>> in a cache line in the CPU for instance. I don't think there is any
>>>> guarantee that b is published correctly. The semantics depend on the
>>>> publication of the container object and participating threads.
>>>> I've seen similar things happen in the 64-bit JVM.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list