[concurrency-interest] LoadStore and StoreStore , are both are required before lazySet and volatile write

Vitaly Davidovich vitalyd at gmail.com
Tue Sep 23 12:35:40 EDT 2014


As I understood it, Thread 1 can see 42 before the increment only because
of reordering of its own operations, allowing x_init to be set earlier and
giving Thread 2 a chance to run before the increment in Thread 1.  I'm not
sure what x == null has to do with it.

Sent from my phone
On Sep 23, 2014 12:13 PM, "Oleksandr Otenko" <oleksandr.otenko at oracle.com>
wrote:

>  When discussing reordering of the dependencies, it was made clear that
> Thread 2 may observe x==null, and still the store of x.a=42 may succeed.
> Depending on the magic involved, Thread 1 may observe x.a==42. So my
> question is mostly about what magic is feasible in modern day technology.
>
>
> Alex
>
>
> On 23/09/2014 17:04, Vitaly Davidovich wrote:
>
> That would be somewhat hard to believe as this means something (compiler
> or cpu) speculated about x_init.load_acquire() returning true but wrote to
> memory beforehand? A cpu can speculate like this, I suppose, but it
> wouldn't be able to actually retire the store of 42 until the speculation
> is proven correct, at which point the store is committed (but then this
> doesn't change observed behavior).  Or did you mean something else?
>
> On Tue, Sep 23, 2014 at 11:54 AM, Oleksandr Otenko <
> oleksandr.otenko at oracle.com> wrote:
>
>>  Is this sufficient?
>>
>> Without LoadStore in the second thread, Thread 2 is allowed to observe x
>> after writing x.a=42. I am not sure what that means to Thread 1.
>>
>> Alex
>>
>>
>> On 22/09/2014 21:31, Vitaly Davidovich wrote:
>>
>> For Hans' example, he's basically saying this:
>> x.a = 0;
>> tmp = x.a; << read of x itself
>> tmp = tmp + 1;
>> x.a = tmp;
>> x.init_store_write_release(true);
>>
>>  The argument is that if only stores are ordered and loads can be
>> reordered with the stores, then the read of x.a could be reordered with the
>> releasing store, i.e.:
>>  x.a = 0;
>> x.init_store_write_release(true);
>>  tmp = x.a; << this load re-ordered with the store and may now see x.a =
>> 42 if thread 2 ran
>> tmp = tmp + 1;
>> x.a = tmp; << results in x.a = 43
>>
>>  As Hans mentions, this is somewhat esoteric and strange.  It would
>> require something (e.g. cpu, compiler) determining/allowing reordering
>> dependent memory operations; in terms of cpu, only one I know that allows
>> this is the Alpha.  But he has a separate argument about not relying on
>> memory dependence to enforce any ordering ...
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 22, 2014 at 3:14 PM, vikas <vikas.vksingh at gmail.com> wrote:
>>
>>>
>>> I was reading a article from Hans and he argues that LoadStore is also
>>> needed before lazySet or a final variable write (i assume then also
>>> before
>>> volatile write).
>>>
>>> He demonstrated a particular race condition which i couldn't understand
>>> (link below).
>>>
>>> http://www.hboehm.info/c++mm/no_write_fences.html see *Recipient writes
>>> to
>>> object*.
>>>
>>> Its very counter intuitive how  * store of x.a = 43* can be done past the
>>> StoreStore barrier in thread 1.
>>> *
>>> x.a = 0; x.a++;
>>> x_init.store_write_release(true);
>>>
>>> and the code that uses x in thread 2 updates it, with e.g.
>>>
>>> if (x_init.load_acquire())
>>>     x.a = 42;*
>>>
>>>
>>> Similar argument here
>>> http://shipilev.net/blog/2014/all-fields-are-final/
>>>
>>> Copying Shiplev here :
>>>
>>> /JSR 133 Cookbook only requires StoreStore, but might also require
>>> LoadStore
>>> barriers. This covers for a corner case when the final field is getting
>>> initialized off some other field which experiences a racy update. *This
>>> corner case can be enabled by runtime optimization which figures out the
>>> final store is not needed, puts the value in the local variable, and
>>> hence
>>> breaks out of ordering guarantees of StoreStore alone*/
>>>
>>> How runtime can figure out that final Store is not needed, also if load
>>> is
>>> getting passed/reorder the StoreStore Barrier then Store to local
>>> Variable
>>> also is getting passed/reorder with the storeStore barrier, *This is the
>>> part i don't quite understand , why store to local variable can reorder
>>> with
>>> StoreStore Barrier. *
>>>
>>> It would be very help full if anybody can explain in more details what is
>>> the race condition they both are mentioning by some simple example.
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://jsr166-concurrency.10961.n7.nabble.com/LoadStore-and-StoreStore-are-both-are-required-before-lazySet-and-volatile-write-tp11291.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 listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140923/1a60b7a0/attachment.html>


More information about the Concurrency-interest mailing list