[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
boehm at acm.org
Thu May 25 19:44:07 EDT 2017
Hopefully CAS no more guarantees a barrier than a volatile access does. The
intent was always to allow all barriers to be elided if the atomic is
If CAS were to guarantee a barrier, neither a lock-based implementation,
not the standard ARMv8 implementation would work.
On Thu, May 25, 2017 at 3:46 PM, Alex Otenko <oleksandr.otenko at gmail.com>
> We also need to keep the StoreLoad barrier before the CAS.
> While it is not needed when the atomic is used (preemptive read is only a
> guess; making a wrong guess still keeps the barriers of the atomic), in the
> “optimized” version preemptive read of the expected value can reorder
> > On 25 May 2017, at 14:59, Nathan and Ila Reynolds <nathanila at gmail.com>
> > > The best we could so here is replace elided volatile write with a full
> fence, which would probably not be detectably faster.
> > I definitely agree with Alex Otenko's position of keeping the
> synchronizes-with edge. I can think of several places in code where
> removing this edge would cause all sorts of wacky hard-to-reproduce
> issues. Doug's suggestion I quoted above seems like a good solution. From
> my limited perspective, his suggestion seems to keep the synchronizes-with
> edge yet avoid the volatile write. I can assure you that replacing a
> volatile write with a full fence is definitely faster. On a highly
> contended cache line, eliding a volatile write will definite improve
> scalability. I can think of one place in code where each write to the cache
> line is very costly in terms of scalability. I've spent a lot of time
> optimizing that code to reduce the number of writes to 1 cache line.
> Before this optimization, cores would sit at 100% utilization but the
> internal execution pipelines were stalled waiting for a highly contended
> cache line.
> > -Nathan
> > On 5/25/2017 4:39 AM, Doug Lea wrote:
> >> On 05/25/2017 06:16 AM, Andrew Haley wrote:
> >>> On 25/05/17 09:16, Gil Tene wrote:
> >>>>> On May 25, 2017, at 12:35 AM, Alex Otenko
> >>>>> <oleksandr.otenko at gmail.com> wrote:
> >>>>> This is a bad idea.
> >>>>> Now there is no guarantee that the synchronizes-with edge
> >>>>> exists.
> >>>> The current Java 9 specification (in the JavaDoc) of
> >>>> AtomicReference.updateAndGet() doesn't say there is such an edge
> >>>> (the Java 8 one did, but the current Java 9 one doesn't).
> >>> Ah, I see:
> >>> "compareAndSet and all other read-and-update operations such as
> >>> getAndIncrement have the memory effects of both reading and writing
> >>> volatile variables. " seems to have gone.
> >> Thanks for pointing this out!
> >> The "...and all other read-and-update operations" clause
> >> inadvertently disappeared while meshing j.u.c.atomic specs
> >> with jdk9 VarHandles
> >> (http://download.java.net/java/jdk9/docs/api/java/lang/
> >> The updateAndGet method is not a part of VarHandles, so is no longer
> >> covered by any existing statement. We will need to somehow do so.
> >> And so, Mike: Some existing code might rely on this, so the best we
> >> could so here is replace elided volatile-write with a fullFence,
> >> which would probably not be detectably faster.
> >> -Doug
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> > --
> > -Nathan
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest