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

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

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.


From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Saturday, October 08, 2011 10:11 AM
To: Boehm, Hans; 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<mailto: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 ...


On Sat, Oct 8, 2011 at 12:06 AM, Boehm, Hans <hans.boehm at hp.com<mailto: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.


From: Vitaly Davidovich [mailto:vitalyd at gmail.com<mailto:vitalyd at gmail.com>]
Sent: Friday, October 07, 2011 5:10 PM
To: Boehm, Hans
Cc: concurrency-interest at cs.oswego.edu<mailto: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>

617-548-7007<tel:617-548-7007> (mobile)

617-548-7007 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111009/9b46f820/attachment-0001.html>

More information about the Concurrency-interest mailing list