[concurrency-interest] Atomic.*lazyGet

Boehm, Hans hans.boehm at hp.com
Thu Aug 9 11:43:59 EDT 2012

I suspect you don't want to go any weaker than the equivalent of C++ memory_order_relaxed.  That guarantees at least cache coherence, i.e. loads from the same memory location can't be reordered.  There are one or two hardware architectures that allow such reordering for naked loads, even if the compiler avoids it.  But even that's quite error prone.  In my experience people commonly assume memory_order_acquire ordering without realizing it.  And it gets us back into the realm where we have to disallow out-of-thin air results, which we don't really know how to do.

I think all the solutions here are quite messy.


> -----Original Message-----
> From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com]
> Sent: Thursday, August 09, 2012 12:06 AM
> To: Boehm, Hans
> Cc: Doug Lea; concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Atomic.*lazyGet
> On 08/09/2012 07:45 AM, Boehm, Hans wrote:
> > I'm confused.  LazySet() does have happens-before semantics.  And I
> > don't think that's changeable without serious code breakage.  It
> > doesn't participate in the total synchronization order.  That doesn't
> > really make sense in the current memory model, since the
> > synchronization order is what determines happens-before semantics.
> > But we kind of know what it's supposed to do.
> Sorry, I was confusing myself. I think the real semantics I wanted from
> weakGet() is "just" the naked memory read. After sleeping on it,
> realized that trying to piggyback on memory effects to make the
> compiler-only barrier is probably a messy idea. Also, it makes some
> assumptions about HMM, which is not something we should probably
> embrace
> in public API.
> > On the other, there is currently a large additional overhead for
> > volatile loads on POWER, which could be avoided by weakGet, even as
> > defined above.
> Yes, I was leaning towards the platforms which have non-marginal
> volatile read cost. Naked memory op, as confusing as it might be for
> JMM, would help in some corner cases.
> -Aleksey.

More information about the Concurrency-interest mailing list