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

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Sep 23 12:13:06 EDT 2014


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 <mailto: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
>>     <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  <mailto: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/8aae5678/attachment-0001.html>


More information about the Concurrency-interest mailing list