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

Vitaly Davidovich vitalyd at gmail.com
Tue Sep 23 13:38:35 EDT 2014


>
> As I understand it, there is nothing in a memory model
> to prevent stores in Thread 2 after the load_acquire from floating up
> past the x_init.store_write_release in Thread 1.


Maybe nothing in memory model, but this would violate control flow
dependency though, wouldn't it? In order for thread 2 to execute the store,
it has to observe x_init being set to true -- there's explicit control
dependency there.  If thread 1 wrote that with a releasing store, then its
preceding stores are also visible at this point, so I don't see how thread
2's store can float above thread 1's releasing store; thread 1's releasing
store can get reordered within its own operations (like the x.a++ example),
causing thread 2 to perform the write at an "earlier" point in thread 1's
program order (is that what you meant?).

On Tue, Sep 23, 2014 at 1:21 PM, Andrew Haley <aph at redhat.com> wrote:

> The key phrase is "it doesn't make sense to enforce ordering based on
> dependencies, since they cannot be reliably defined *at this level*."
>
> In other words, once you start translating the example into machine
> instructions you can nail it down in ways that aren't imposed by the
> memory model.  As I understand it, there is nothing in a memory model
> to prevent stores in Thread 2 after the load_acquire from floating up
> past the x_init.store_write_release in Thread 1.
>
> Andrew.
>
>
> On 09/23/2014 05:04 PM, 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> 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
> @cs.oswego.eduhttp://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/96927d19/attachment.html>


More information about the Concurrency-interest mailing list