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

Andrew Haley aph at redhat.com
Tue Sep 23 13:21:24 EDT 2014


The key phrase is "it doesn't make sense to enforce ordering based on
dependencies, since they cannot be reliably defined *at this level*."

In other words, once you start translating the example into machine
instructions you can nail it down in ways that aren't imposed by the
memory model.  As I understand it, there is nothing in a memory model
to prevent stores in Thread 2 after the load_acquire from floating up
past the x_init.store_write_release in Thread 1.

Andrew.


On 09/23/2014 05:04 PM, 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
>>
>>
>>
> 
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 



More information about the Concurrency-interest mailing list