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

Vitaly Davidovich vitalyd at gmail.com
Fri Oct 7 20:09:45 EDT 2011


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
> > v=2
> >
> > is allowed reordering?
> Correct.
>
> Hans
>
> _______________________________________________
> 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/20111007/d6bd4ed5/attachment-0001.html>


More information about the Concurrency-interest mailing list