[concurrency-interest] final field/constructor visibility (cf. CyclicBarrier)

Zhong Yu zhong.j.yu at gmail.com
Sun Sep 28 18:30:20 EDT 2014


On Sun, Sep 28, 2014 at 10:43 AM, Yuval Shavit <yankee.sierra at gmail.com> wrote:
> This is somewhat related to a discussion I started here on synchronized
> constructors (specifically, why they're not allowed). In particular:
> http://cs.oswego.edu/pipermail/concurrency-interest/2011-December/008634.html

The conclusion of that thread is that synchronized constructor *works*
even with unsafe publication. See
http://cs.oswego.edu/pipermail/concurrency-interest/2011-December/008642.html

I made the opposite and wrong assertion in that thread, which
fortunately was corrected by others. Sorry about that.

thurstonn's code with locking inside constructor should work as he expected.

Zhong Yu
bayou.io


>
> The short of it is that your code is _still_ not safe in the face of unsafe
> publication. Yes, you establish HB relationships between the lock/unlock in
> the constructor and other lock/unlocks -- but you still haven't guaranteed
> that the constructor is seen first, as un-intuitive as that sounds. Some
> thread could see (for instance) a getter invoked before the constructor. In
> that case, the default value happens-before the getter, which happens-before
> the constructor. Clearly, that's not helpful, but it's valid according to a
> strict reading of the JMM.
>
> To be safe even in the face of unsafe publication, you'd need to not just
> establish just any old HB edge, but more precisely to ensure that the
> constructor happens-before everything else. One way to do that could be:
>
>     volatile boolean ctorFinished;
>
>     CyclicBarrier(int parties) {
>         // lock/unlock, set this.count and this.parties...
>         ctorFinished = true;
>     }
>
>     int getCount() {
>         while (!ctorFinished) {} // spin, wait for the ctor to finish on the
> instantiating thread
>         this.lock.lock();
>         // etc
>     }
>
>
>
> On Sun, Sep 28, 2014 at 3:18 AM, thurstonn <thurston at nomagicsoftware.com>
> wrote:
>>
>> But why not as I referenced?
>>
>> <code>
>> CyclicBarrier(int parties)
>>     this.lock.lock();
>>     this.count = parties;
>>     this.lock.unlock();
>>     this.parties = parties;
>>
>> </code>
>>
>>
>> Is it just somehow unappealing/ungainly (not often you see self-lock
>> acquisition in a constructor - can't say I like it that much)?
>>
>> Of course you're right about safe publication,and I should have referenced
>> the fact that it's only unsafe in the face of improper publication.
>>
>> Still I think it's valuable to have j.u.c objects be "either null or
>> multi-thread safe" where possible (e.g. ReentrantLock)
>>
>>
>>
>> --
>> View this message in context:
>> http://jsr166-concurrency.10961.n7.nabble.com/final-field-constructor-visibility-cf-CyclicBarrier-tp11306p11309.html
>> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> 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