[concurrency-interest] synchronized constructors

Rémi Forax forax at univ-mlv.fr
Thu Dec 15 19:43:57 EST 2011


On 12/16/2011 01:13 AM, Vitaly Davidovich wrote:
>
> 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 :).
>

In practice programs without final/synchronized in the constructor works
because on x86/x64 and modern sparc a storestore is a no-op,
so all codes works until you try to run them on arm ...

Rémi

> On Dec 15, 2011 6:54 PM, "Yuval Shavit" <yshavit at akiban.com 
> <mailto: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 <mailto: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
>         <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111216/bc70063d/attachment-0001.html>


More information about the Concurrency-interest mailing list