[concurrency-interest] non-concurrent collection visibility question

Valentin Kovalenko valentin.male.kovalenko at gmail.com
Sat Jan 6 11:40:40 EST 2018


Hi Andriy,

The answer to your question lies in the specification of "AFTER" order of
actions that you are using.

If by "AFTER" you mean an "order according to wall clock", then there is
nothing you can say about visibility based on such an order.

If by "AFTER" you mean happens-before order, that is B AFTER A if and only
if A happens-before B, then according to your description, all writes to
buffers list happens-before all reads done by receive() method. This means
that your receive() method is guaranteed to see all buffers that were added
to buffers list.

However, since you did not specify "AFTER" in the question, no one can say
what it means, except for you. So could you please specify what did you
mean by "AFTER"?

I would also discourage anyone from using such misleading words like
before/after (without specifying the order you are talking about),
immediately or visible immediately when reasoning about visibility in
multithread programming.

Regards,
Valentin

------------------------------
>
> Message: 2
> Date: Sat, 6 Jan 2018 16:06:41 +0000 (UTC)
> From: Andriy Bukatar <buka1974 at yahoo.com>
> To: "concurrency-interest at cs.oswego.edu"
>         <concurrency-interest at cs.oswego.edu>
> Subject: [concurrency-interest] non-concurrent collection visibility
>         question
> Message-ID: <894991254.1593625.1515254801366 at mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
>   Hi all,
>  First of, Happy New Year everyone and all the best in 2018! Secondly,
> have a question that should be easy to answer for most of you here . In
> some class (say AggregateBuffer) that has a method dispatching multiple
> buffers, we have a collection that holds references to those ring
> buffers: final List<Buffer> buffers = new ArrayList<>(); //simple array
> list, non-concurrent collection  Then we have a method to add a new
> publisher (effectively a new buffer). The buffer gets created and gets
> added to the array list. We know that this method always gets called by the
> same bootstrap-thread that wires all the components.  Publisher<M>
> addPublisher(){       Buffer buffer = new Buffer();
> buffers.add(ringBuffer);} And finally we have a dispatching thread that
> calls receive() method on the AggregateBuffer class scrolling over the
> buffer collection and dispatching each buffer one by one using some
> dispatching strategy (say attempt to read up to N messages at a time from
> each buffer)      int receive()    {        for (Buffer buf:buffers)//the
> line in question        {            buffer.read()        }    } The
> question is -     if we make sure that the dispatcher-thread gets created
> and gets passed the reference to the AggregateBuffer class AFTER all the
> calls to addPublisher() are done with, is it guaranteed that
> dispatcher-thread will see all the changes to the non-concurrent "buffers"
> collection and if so then what guarantees that? In other words – is it
> possible that a dispatcher-thread may see an empty “buffers”
> collection?    thank you
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cs.oswego.edu/pipermail/concurrency-
> interest/attachments/20180106/e3f1404d/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> ------------------------------
>
> End of Concurrency-interest Digest, Vol 156, Issue 3
> ****************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180106/526e9782/attachment.html>


More information about the Concurrency-interest mailing list