[concurrency-interest] synchronized constructors

Yuval Shavit yshavit at akiban.com
Thu Dec 15 18:53:53 EST 2011

>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111215/f2e6795a/attachment.html>

More information about the Concurrency-interest mailing list