[concurrency-interest] AtomicReference.updateAndGet() mandatory updating

Justin Sampson jsampson at guidewire.com
Thu May 25 11:03:53 EDT 2017

Are AtomicStampedReference and AtomicMarkableReference going to have this optimization removed from all of their methods for consistency, or will they be called out differently in the docs?


On 5/25/17, 3:39 AM, "Concurrency-interest on behalf of Doug Lea" <concurrency-interest-bounces at cs.oswego.edu on behalf of dl at cs.oswego.edu> 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
    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.

More information about the Concurrency-interest mailing list