Reference assignment is atomic so why use AtomicRe

Question

I have simple general question about AtomicReference.

Why use AtomicReference if reference assignment is atomic in java?

Also I would like to ask if reference assigment is atomic in 64-bit VMs?

Do we need volatile to have reference assigment atomic?

Answer 1

Why use AtomicReference if reference assignment is atomic in java?

You need it when the decision on which the creation of the new value is based can depend on the previous value of the reference. For instance when implementing some LinkedList like data structure you wan't to set the head to a new node which refers to the previous node. In the time between reading the previous node and setting head to the new one some other thread could have concurrently updated the head reference's value. If our thread would not be aware of this change, it would go lost.

Do we need volatile to have reference assigment atomic?

The operation itself would be performed atomic on the CPU core executing it but there are no guarantees that threads on other cores will be aware of it on the next read.

Answer 2

My previous answer was incorrect, as explained in the comment by juancn:

That's the difference between Atomic* classes and volatile access. Reference assignment is atomic only in the sense that no word tearing can occur, but there's no visibility or reordering guarantees. Java guarantees atomic writes in this restricted sense for all primitive types and references but not for long/double (although in 64bit VMs I think they're always atomic).

Previous answer

It is necessary, mainly for compareAndSet and getAndSet methods. You cannot do this atomically otherwise (2 operations are needed).

Answer 3

The reason is that even though the reference is atomic, it is atomic in a very narrow sense.

If a thread writes a non volatile reference, what is guaranteed is that other threads will see the whole write or not see it at all (no word tearing/garbage).

But at no point it is guaranteed that any other thread will ever see it nor that they will be seen in the same order.

An AtomicReference provides much stronger guarantees (besides the CAS operations), essentially they behave like volatile:

• Any writes that happened in thread A before a volatile write are visible in thread B after a subsequent volatile read of that variable
• volatile operations cannot be reordered