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

Valentin Kovalenko valentin.male.kovalenko at gmail.com
Sat Sep 27 12:28:07 EDT 2014


Yes, you a right, if CB published via data race then JMM doesn't guarantee
that write to the field CB.count made in constructor will be visible to a
thread that didn't created CB instance. But it doesn't mean that CB is
broken, because CB's specification doesn't tell you that you'r allowed to
publish instances of CB via data race. The same is true for many classes
(e.g. AtomicLong and Co).




*>>As a side note, this is not the situation that generally causes
confusionwith respect to final field visibility guarantees, e.g. where a
constructorwrites a final Map field and then populates the Map (I think
that's beensettled?)*
In this case final semantics works.

On Sat, Sep 27, 2014 at 8:00 PM, <concurrency-interest-request at cs.oswego.edu
> wrote:

> Send Concurrency-interest mailing list submissions to
>         concurrency-interest at cs.oswego.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
>         concurrency-interest-request at cs.oswego.edu
>
> You can reach the person managing the list at
>         concurrency-interest-owner at cs.oswego.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
>
>
> Today's Topics:
>
>    1. final field/constructor visibility (cf.   CyclicBarrier) (thurstonn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 27 Sep 2014 04:35:23 -0700 (MST)
> From: thurstonn <thurston at nomagicsoftware.com>
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] final field/constructor visibility
>         (cf.    CyclicBarrier)
> Message-ID: <1411817723290-11306.post at n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> I have a question regarding the memory semantics of a constructor that sets
> both a final and non-final field.
>
> It was triggered by looking at j.u.c.CyclicBarrier which is defined:
>
> <code>
> final int parties
> int count
>
> CyclicBarrier(int parties)
>    this.parties = parties;
>    this.count = parties;
> </code>
>
> Now my understanding of the JMM is that any thread referencing the CB is
> guaranteed to see  CB#parties as expected, but there is no guarantee that a
> thread can't see CB#count = 0 //initialized state, i.e. the fact that the
> constructor sets a final variable (#parties) has no bearing at all on any
> guarantees of the visibility of #count (and as a side note, the code order
> of the writes has no bearing at all either, i.e.
>
> <code>
> final int parties
> int count
>
> CyclicBarrier(int parties)
>     this.count = parties;
>     this.parties = parties;
>
> </code>
>
> has the same issue.
>
> So the following is theoretically possible
> T1                            T2
> x = new CB(5)             assert x.getCount() == 5  //may fail
>
> Now CB takes great care that all access of #count is under protection of a
> lock (both reads and writes), but there is no happens-before edge between
> the constructor writing to non-final #count and T2 (or T3, T4) acquiring
> the
> lock and then reading #count.
> In short (although there is a high presumption that the JDK is correct), CB
> does not look multi thread-safe (to me).
>
> I was expecting to see:
>
> <code>
> CyclicBarrier(int parties)
>     this.lock.lock();
>     this.count = parties;
>     this.lock.unlock();
>     this.parties = parties;
>
> </code>
> or something similar (of course the lock#lock() would be uncontended and so
> shouldn't present any substantial performance cost); this would provide the
> necessary happens-before edge (release of lock happens-before any
> subsequent
> acquisition of said lock).
>
>
> As a side note, this is not the situation that generally causes confusion
> with respect to final field visibility guarantees, e.g. where a constructor
> writes a final Map field and then populates the Map (I think that's been
> settled?)
>
> Someone want to set me straight?
>
>
>
>
>
>
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/final-field-constructor-visibility-cf-CyclicBarrier-tp11306.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
>
>
> End of Concurrency-interest Digest, Vol 116, Issue 29
> *****************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140927/880764f3/attachment.html>


More information about the Concurrency-interest mailing list