[concurrency-interest] AtomicXXX.lazySet and happens-before reasoning

Ruslan Cheremin cheremin at gmail.com
Sun Oct 9 18:03:53 EDT 2011


The farther, the better :)

Yes, from this atomic package javadoc specification it is clear that it is
not only StoreStore, but also LoadStore barriers before lazySet.

Interestingly that my meeting with lazySet started from informal definition
like "non-volatile write to volatile variable with few additional ordering
constraints", but for now it is "has the memory effects of writing
(assigning) a volatile variable except..."


That is not clear for me -- doesn't strict volatile store prevents any
reordering with subsequent memory actions? Huns, you've just present an
example of such allowed reordering.

It seems like it somekind related to StoreLoad fence which ordinary volatile
store must has after it (although I still do not understand why), but
lazySet omit?



> The specification states****
>
> ** **
>
> **·         **lazySet has the memory effects of writing (assigning) a
> volatile variable except that it permits reorderings with subsequent (but
> not previous) memory actions that do not themselves impose reordering
> constraints with ordinary non-volatile writes. Among other usage contexts,
> lazySet may apply when nulling out, for the sake of garbage collection, a
> reference that is never accessed again. ****
>
> in the java.util.concurrent description, which implies that it may not be
> reordered with previous “memory actions”, not just stores.  Doug can comment
> more authoritatively on the intent, but that specification seems fairly
> unambiguous in this particular respect.****
>
> ** **
>
> Hans****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com <javascript:_e({},
> 'cvml', 'vitalyd at gmail.com');>]
> *Sent:* Saturday, October 08, 2011 10:11 AM
> *To:* Boehm, Hans; concurrency-interest at cs.oswego.edu <javascript:_e({},
> 'cvml', 'concurrency-interest at cs.oswego.edu');>
> *Subject:* Re: [concurrency-interest] AtomicXXX.lazySet and happens-before
> reasoning****
>
> ** **
>
> + rest of the group****
>
> On Sat, Oct 8, 2011 at 1:10 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:****
>
> Hi Hans,****
>
> ** **
>
> I was under the impression that lazySet is purely a StoreStore barrier, and
> only specifies that the lazySet cannot be reordered with prior writes -- I
> never saw mention of requiring no reordering with prior loads.  Here's
> Doug's evaluation:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6275329, where only a
> store-store is mentioned.  If it's really a LoadStore | StoreStore, good to
> know ...****
>
> ** **
>
> Thanks****
>
> ** **
>
> On Sat, Oct 8, 2011 at 12:06 AM, Boehm, Hans <hans.boehm at hp.com> wrote:***
> *
>
> LazySet() needs to prevent reordering of ordinary memory operations with a
> subsequent lazySet() operation.  In the JSR 133 Cookbook style, that can be
> implemented with a LoadStore | StoreStore fence preceding the lazySet()
> call.  So yes, that makes sense.****
>
>  ****
>
> Real machines tend to require neither of those fences (x86) or combine them
> into a single instruction.****
>
>  ****
>
> Hans****
>
>  ****
>
> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com]
> *Sent:* Friday, October 07, 2011 5:10 PM
> *To:* Boehm, Hans
> *Cc:* concurrency-interest at cs.oswego.edu; Ruslan Cheremin****
>
>
> *Subject:* Re: [concurrency-interest] AtomicXXX.lazySet and happens-before
> reasoning****
>
>  ****
>
> Does it even make sense to say that lazySet needs a LoadStore fence? The
> get() does but that's because it has same semantics as volatile read. ****
>
> On Oct 7, 2011 7:29 PM, "Boehm, Hans" <hans.boehm at hp.com> wrote:****
>
> > From: Ruslan Cheremin [mailto:cheremin at gmail.com]
> > > It also needs a LoadStore fence, in both cases.
> >
> > But why lazySet needs LoadStore fence? It seems what lazySet javadoc
> > does not put any ordering constraints on loads...
> I do read it as imposing such a constraint, though we all agree that a more
> precise spec would help.  Certainly C++11's memory_order_release imposes
> such a constraint.
>
> If not, it would mean that e.g.
>
> Thread 1:
> x = ...;
> ...
> r1 = x;
> done_with_x.lazySet(true);
>
> Thread 2:
> if (done_with_x.get()) {
>   x = ...;
>   ...
>   r2 = x;
> }
>
> wouldn't work as expected.
>
> In my opinion, that's an indefensible design point, especially since I
> don't believe it makes lazySet appreciably cheaper on any modern
> architectures.
>
>
> >
> > > In particular, if v is volatile (and certainly if it's accessed using
> > lazySet), and x and y are ordinary variables,
> > > then the assignments to x and y in the following may be visibly
> > reordered:
> > > x = 1;
> > > v = 2;
> > > y = 3;
> >
> > You mean what vstore is not "transparent" upside down, but
> > "transparent" downside up, so this
> >
> > y=3
> > x=1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111010/e2a450c9/attachment.html>


More information about the Concurrency-interest mailing list