[concurrency-interest] AtomicReferenceFieldUpdater - methods set, get, compareAndSet semantics

Ruslan Cheremin cheremin at gmail.com
Wed Dec 7 05:57:26 EST 2011

There is an interesting discussion on stackoverflow
-- about j.u.c.ARFUpdater spec. The confusing part of spec is:

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.

As one of users supposed, this part of spec is about atomics
implementation on platforms without hardware support for atomic
instructions. So, atomics there must be emulated with locks, and, to
preserve atomicity of CAS-like operations, all accesses must be done
throught ARFUpdater methods, and not via direct field access (for
stores, actually -- direct field loads seems to be OK).

This interpretation seems to be legal and consistent, but nobody can't
find direct authoritive sources, which support such interpretation.
Can somebody clearify the reasoning behind this part of spec?

Cheremin Ruslan

More information about the Concurrency-interest mailing list