[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?

Cheers,
Justin


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
    (http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html)
    
    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
 



More information about the Concurrency-interest mailing list