[concurrency-interest] Difference between AtomicReference.getPlain() and getOpaque()

Florian Weimer fw at deneb.enyo.de
Sun Oct 15 05:23:09 EDT 2017


* Andrew Haley:

> On 15/10/17 09:38, Florian Weimer wrote:
>> Are these methods essentially the same?  I think so, based on JLS §17.7:
>> 
>> | Writes to and reads of references are always atomic, regardless of
>> | whether they are implemented as 32-bit or 64-bit values.
>> 
>> I assume there is a difference between getPlain() and getOpaque() for
>> AtomicLong because of potentially non-atomic access: I assume
>> getOpaque() rules that out (but that is not very clear), but
>> getPlain() obviously does not.
>
> Consider a reference field x, and a loop:
>
> while (x == null) { }
>
> and another thread
>
> x = new Object();
>
> If x is not volatile, Java compiler can hoist the load of x out of a loop
> and turn that loop into
>
> for (;;) { }
>
> ... so it loops forever.
>
> However, it cannot do the same with getOpaque().  Eventually the read of
> x will return non-null, although it may be delayed for a long time and it
> won't be ordered with any other accesses.

Thanks, with this and (the reference Никита provided), it's clear that
they are not the same.  It's really not obvious based on JLS 9 and the
JDK 9 API documentation that there are additional constraints on the
implementation here.  The description of the memory model in the JLS
could at least say that it's not been updated for the introduction of
opaque accesses in JDK 9. 8-/


More information about the Concurrency-interest mailing list