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

Vitaly Davidovich vitalyd at gmail.com
Mon Sep 22 16:31:58 EDT 2014


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140922/747c7a67/attachment.html>


More information about the Concurrency-interest mailing list