[concurrency-interest] AtomicReference.updateAndGet() mandatory updating
gil at azul.com
Thu May 25 13:15:24 EDT 2017
Sent from my iPad
> On May 25, 2017, at 3:42 AM, Doug Lea <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
>>> 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
While on this subject, was the relative "weakening" of compareAndSet (and other) memory semantics between Java 8 and java 9 discussed elsewhere?
In java 8, a compareAndSet has the memory semantics of a volatile write regardless of whether or not the write occurred. In java 9 it only has a volatile write effect if the write occurs. While the loosening in the non-writing case may allow for additional optimizations, I worry that it may break existing code that could rely on the previous behavior.
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest