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

Vitaly Davidovich vitalyd at gmail.com
Tue Sep 23 12:04:20 EDT 2014


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/c9b36fcf/attachment.html>


More information about the Concurrency-interest mailing list