[concurrency-interest] non-concurrent collection visibility question

Valentin Kovalenko valentin.male.kovalenko at gmail.com
Sat Jan 6 13:08:01 EST 2018


Great, then you are OK.

Regards,
Valentin

On 6 January 2018 at 21:04, Andriy Bukatar <buka1974 at yahoo.com> wrote:

> Thanks very much Valentin. Actually your last statement about Program
> Order addresses my question in its entirety - T1 is a boot-strap thread
> that creates all the machinery and starts all the receivers (like T2) after
> it adds all the buffers to L.
>
> I believe this is the guarantee I was looking for.
>
> Thank you
>
>
>
> On Jan 6, 2018, at 12:50 PM, Valentin Kovalenko <valentin.male.kovalenko@
> gmail.com> wrote:
>
> Thank you for the clarification. In this case, read actions in T2 are not
> ordered by happens-before order (HB) with the write actions in T1. And all
> these actions act on the same shared variables (fields of the list L). So
> by definition, you have a data race. And there is no guarantee that you
> will correctly read all the buffers that T1 added to the L.
>
> I want to add, that generally there is no guarantee that you will see a
> non-null when reading L field from T2. However is your case this field is
> final, and the semantics of a final field guarantees HB* between a write to
> the field L (T1 writes there a reference to a new ArrayList()) and a read
> of the reference from L field in T2. Unfortunately, this HB* is not
> transitive with the normal HB, hence you don't have guarantees you
> initially asked about.
>
> And one more thing: if you had started T2 from T1 after (in program order
> (PO)) T1 added all buffers to L, then you would have had HB between all
> actions in T1 (which are ordered in PO before the start of T2) and all
> actions in T2. But as far as I understand, your case is different and T2 is
> started not from T1.
>
> Regards,
> Valentin
>
> On 6 January 2018 at 20:07, Andriy Bukatar <buka1974 at yahoo.com> wrote:
>
>> Thanks Valentin.
>> Yes, the devil is in the details.
>>
>> I could rephrase the question as follows:
>>
>> There’s a class C containing the non-concurrent list L.
>>
>> Thread T1 adds a few items to the list L.
>>
>> Thread T2 starts (note it did not exist at the time when T1 was updating
>> the list L). Thread T2 gets a reference to C and iterates over its list L.
>>
>> So “AFTER” in this case is a “wall clock distance” between the time T1
>> performs the last update to L and the time when T2 starts.
>>
>> I know the answer to this question when T2 starts iterating over L before
>> (or at the time when) T1 performs updates to non-concurrent L - no
>> visibility guarantees whatsoever.
>>
>> The question I suppose is whether non-existence of T2 at the time of the
>> last update to L has any impact on visibility of the contents of L.
>>
>> Not sure if this makes it any clearer and my apologies if it does not.
>>
>> Thank you
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180106/f1f8f4b6/attachment.html>


More information about the Concurrency-interest mailing list