AtomicReferenceFieldUpdater - methods set, get, compareAndSet semantics

Question

From the Java AtomicReferenceFieldUpdater docs:

Note that the guarantees of the compareAndSet method in this class are weaker than in other atomic classes. Because this class cannot ensure that all uses of the field are appropriate for purposes of atomic access, it can guarantee atomicity and volatile semantics only with respect to other invocations of compareAndSet and set.

This means I can't do normal volatile writes along with compareAndSet, but have to use set instead. It doesn't mention anything about get.

Does that mean that I can still read volatile fields with the same atomicity guarantees - all writes before the set or compareAndSet are visible to everybody who has read the volatile field being?

Or do I have to use get on the AtomicReferenceFieldUpdater instead of volatile reads on the field?

Please post references if you have them.

Thank you.

EDIT:

From Java Concurrency in Practice, the only thing they say:

The atomicity guarantees for the updater classes are weaker than for the regular atomic classes because you cannot guarantee that the underlying fields will not be modified directly — the compareAndSet and arithmetic methods guarantee atomicity only with respect to other threads using the atomic field updater methods.

Again, no mention of how the other threads are supposed to read these volatile fields.

Also, am I right to assume that "modified directly" is a regular volatile write?

Answer 1

As explained in the package documentation for atomics (in general, not the updaters specifically):

The memory effects for accesses and updates of atomics generally follow the rules for volatiles, [...]:

• get has the memory effects of reading a volatile variable.
• set has the memory effects of writing (assigning) a volatile variable.
• [...]
• compareAndSet and all other read-and-update operations such as getAndIncrement have the memory effects of both reading and writing volatile variables.

What problem is an atomic's compareAndSet trying to solve? Why use (for example) atomicInteger.compareAndSet(1,2) instead of if(volatileInt == 1) { volatileInt = 2; }? It's not trying to solve any problem with concurrent reads, because those are already taken care of by a regular volatile. (A "volatile" read or write is the same as an "atomic" read or write. A concurrent read would only be a problem if it happened in the middle of a write, or if statements were reordered or optimized in some problematic way; but volatile already prevents those things.) The only problem that compareAndSet solves is that, in the volatileInt approach, some other thread might come in with a concurrent write, between when we read volatileInt (volatileInt == 1) and when we write to it (volatileInt = 2). compareAndSet solves this problem by locking out any competing writes during that time.

This is equally true in the specific case of the "updaters" (AtomicReferenceFieldUpdater etc.): volatile reads are still just peachy. The updaters' compareAndSet methods' only limitation is that, instead of "locking out any competing writes" as I wrote above, they only lock out competing writes from the same instance of AtomicReferenceFieldUpdater; they can't protect you when you're concurrently updating a volatile field directly (or, for that matter, when you're concurrently using multiple AtomicReferenceFieldUpdaters to update the same volatile field). (Incidentally, depending how you look at it — the same is true of AtomicReference and its kin: if you were to update their fields in a way that bypassed their own setters, they couldn't protect you. The difference is that an AtomicReference actually owns its field, and it's private, so there's no need to warn you against somehow modifying it by external means.)

So, to answer your question: Yes, you can continue to read volatile fields with the same atomicity guarantees against partial/inconsistent reads, against statements being reordered, etc.

---

Edited to add (Dec 6): Anyone who's particularly interested in this subject will probably be interested in the discussion immediately below. I was asked to update the answer to clarify salient points from that discussion:

• I think the most important point to add is that the above is my own interpretation of the documentation. I'm fairly confident that I have understood it correctly, and that no other interpretation makes sense; and I can, if desired, argue the point at length ;-) ; but neither I nor anyone else has produced any references to any authoritative document that addresses this point any more explicitly than the two documents mentioned in the question itself (the class's Javadoc and Java Concurrency in Practice) and the one document mentioned in my original answer to it above (the package's Javadoc).

• The next most important point, I think, is that although the documentation for AtomicReferenceUpdater says that it's unsafe to mix compareAndSet with a volatile write, I believe that on typical platforms it actually is safe. It's unsafe only in the general case. I say this because of the following comment from the package documentation:

  The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors. However on some platforms, support may entail some form of internal locking. Thus the methods are not strictly guaranteed to be non-blocking -- a thread may block transiently before performing the operation.

  So:

  • In a typical JDK implementation for a modern processor, AtomicReference.set simply uses a volatile write, since AtomicReference.compareAndSet uses a compare-and-swap operation that is atomic with respect to volatile writes. AtomicReferenceUpdater.set is necessarily more complex than AtomicReference.set, because it has to use reflection-like logic to update a field in another object, but I maintain that that is the only reason it is more complex. A typical implementation calls Unsafe.putObjectVolatile, which is a volatile write by longer name.
  • But not all platforms support this approach, and if they don't, then blocking is permitted. At the risk of oversimplifying, I take this to mean roughly that an atomic class's compareAndSet could be implemented by (more or less) applying synchronized to a method that uses get and set straightforwardly. But for this to work, set must also be synchronized, for the reason explained in my original answer above; that is, it can't just be a volatile write, because then it could modify the field after compareAndSet has called get but before compareAndSet calls set.
  • Needless to say, my original answer's use of the phrase "locking out" shouldn't be taken literally, since on a typical platform nothing very lock-like need occur.

• In Sun's JDK 1.6.0_05 implementation of java.util.concurrent.ConcurrentLinkedQueue<E>, we find this:

  private static class Node<E> {
      private volatile E item;
      private volatile Node<E> next;
      private static final AtomicReferenceFieldUpdater<Node, Node> nextUpdater =
          AtomicReferenceFieldUpdater.newUpdater(Node.class, Node.class, "next");
      private static final AtomicReferenceFieldUpdater<Node, Object> itemUpdater =
          AtomicReferenceFieldUpdater.newUpdater(Node.class, Object.class, "item");
      Node(E x) { item = x; }
      Node(E x, Node<E> n) { item = x; next = n; }
      E getItem() { return item; }
      boolean casItem(E cmp, E val)
          { return itemUpdater.compareAndSet(this, cmp, val); }
      void setItem(E val) { itemUpdater.set(this, val); }
      Node<E> getNext() { return next; }
      boolean casNext(Node<E> cmp, Node<E> val)
          { return nextUpdater.compareAndSet(this, cmp, val); }
      void setNext(Node<E> val) { nextUpdater.set(this, val); }
  }
  

  (note: whitespace adjusted for compactness), where, once an instance has been constructed, there are no volatile writes — that is, all writes are via AtomicReferenceFieldUpdater.compareAndSet or AtomicReferenceFieldUpdater.set — but volatile reads appear to be used freely, without a single call to AtomicReferenceFieldUpdater.get. Later releases of JDK 1.6 were changed to use Unsafe directly (this had happened by Oracle's JDK 1.6.0_27), but discussions on the JSR 166 mailing list attribute this change to performance considerations rather than to any qualm about the correctness of the previous implementation.

  • But I must point out that this is not bullet-proof authority. For convenience, I write of "Sun's implementation" as though it had been a unitary thing, but my previous bullet-point makes obvious that JDK implementations for different platforms may have to do things differently. The above code seems to me to have been written in a platform-neutral way, since it eschews plain volatile writes in favor of calls to AtomicReferenceFieldUpdater.set; but someone who doesn't accept my interpretation of the one point may not accept my interpretation of the other, and might argue that the above code is not meant to be safe for all platforms.
  • Another weakness of this authority is that, although Node seems to allow volatile reads to take place concurrently with calls to AtomicReferenceFieldUpdater.compareAndSet, it's a private class; and I have not undertaken any proof that its owner (ConcurrentLinkedQueue) actually makes such calls without its own precautions. (But although I have not proven the claim, I doubt that anyone would dispute it.)

Please see the below comments for background on this addendum, and for further discussion.

Answer 2

What this means is that the reference to the object will be guaranteed but because you can use any object, the fields of that object may not be properly written when another thread goes to access the object.

The only way that could be guaranteed is if the fields were final or volatile.

Answer 3

This will not be an exact answer of the question:

Neither explanation, nor intent looks clear from the documentation. If the idea was to bypass global ordering aka volatile write on architectures that allow it [like IBM Power or ARM] and just expose CAS (LoadLinked/StoreCondition) behavior WITHOUT fencing, it'd quite an amazing effort and source of confusion.

sun.misc.Unsafe's CAS has no specification or ordering guarantees (known as happens before) but java.util.atomic... does. So on weaker model java.util.atomic impl. would require necessary fences to follow java specification in this case.

Assuming Updater classes actually lack the fences. If they do so, volatile read of field (w/o using get) shall return the update value, i.e. clearly get() is unneeded. Since there won't be ordering guarantees, the previous stores might not be propagate (on weak models). On x86/Sparc TSO hardware ensures java spec.

However, that also means CAS can be reordered with following non-volatile reads. There is an interesting note from java.util.concurrent.SynchronousQueue queue:

        // Note: item and mode fields don't need to be volatile
        // since they are always written before, and read after,
        // other volatile/atomic operations.

All atomic operation mentioned are exactly CAS of AtomicReferenceFieldUpdater. That would imply the lack or reording between normal reads AND writes and AtomicReferenceFieldUpdater.CAS, i.e. acting like volatile write.

        s.item = null;   // forget item
        s.waiter = null; // forget thread

        //....

        while ((p = head) != null && p != past && p.isCancelled())
            casHead(p, p.next);

Just CAS, no volatile writes.

Given the condition above, I'd conclude the AtomicXXXFieldUpdater expose the same semantics as their AtomicXXX counterparts.