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

Boehm, Hans hans.boehm at hp.com
Sat Oct 8 00:06:08 EDT 2011

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.


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<mailto:hans.boehm at hp.com>> wrote:
> From: Ruslan Cheremin [mailto:cheremin at gmail.com<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;

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?


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111008/bcf9a553/attachment.html>

More information about the Concurrency-interest mailing list