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

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Sep 23 11:54:44 EDT 2014


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 
> <mailto: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
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140923/83a9e7bf/attachment-0001.html>


More information about the Concurrency-interest mailing list