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

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


x==null is evidence that Thread 2 observed the operations in the 
opposite order (opposite to "program order"). Then the question is 
whether Thread 1 can see them in the opposite order too.

Alex

On 23/09/2014 17:35, Vitaly Davidovich wrote:
>
> As I understood it, Thread 1 can see 42 before the increment only 
> because of reordering of its own operations, allowing x_init to be set 
> earlier and giving Thread 2 a chance to run before the increment in 
> Thread 1.  I'm not sure what x == null has to do with it.
>
> Sent from my phone
>
> On Sep 23, 2014 12:13 PM, "Oleksandr Otenko" 
> <oleksandr.otenko at oracle.com <mailto:oleksandr.otenko at oracle.com>> wrote:
>
>     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/15b769aa/attachment-0001.html>


More information about the Concurrency-interest mailing list