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

thurstonn thurston at nomagicsoftware.com
Sun Sep 28 03:18:44 EDT 2014


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.


More information about the Concurrency-interest mailing list