[concurrency-interest] question about spec for AtomicIntegerFieldUpdater

Josh Humphries jh at squareup.com
Mon Dec 8 09:15:40 EST 2014


Hey, all (particularly Doug Lea, who's in the @author tag for this class):

The second paragraph of the class doc for this class:

Note that the guarantees of the {@code 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 only with respect to other invocations of {@code
> compareAndSet} and {@code set} on the same updater.


The implementations for these methods (compareAndSet() and set()) use
sun.misc.Unsafe to do compareAndSwap for the first and volatile write for
the second.

But in AbstractQueuedSynchronizer, the same unsafe semantics are used for
the CAS. However, setState() does a standard field assignment to get the
volatile write (instead of using Unsafe, like AtomicIntegerFieldUpdater).

If it's okay to mix standard field assignment for the volatile write and
unsafe for CAS, what is the potential issue to which
AtomicIntegerFieldUpdater doc refers, about weaker guarantees?

At first, I saw this in the AtomicLongFieldUpdater and assumed it was
related to whether a JVM could do an atomic 64-bit CAS (and has a
lock-based implementation if not). So it makes sense for this case why
callers might need to use updater.set() for the CAS operation to work
correctly.

But I was confused to see it for its 32-bit sibling. Also,
AtomicLongQueuedSynchronizer doesn't check whether the VM can do atomic
64-bit swaps and does the same thing as AtomicQueuedSynchronizer -- always
use unsafe to do the CAS and standard field assignment to achieve the
volatile write.

In the end, I'm curious because I don't want to pay the overhead of runtime
type checks in calling AtomicIntegerFieldUpdater.set(). But I do want to
use the CAS operation, prefer the idea of laying out the variable into the
class (as opposed to using AtomicInteger and chasing a pointer) and would
prefer to never rely on sun.misc.Unsafe.

So, what are the hazards of using AtomicIntegerFieldUpdater (and
AtomicLongFieldUpdater) for compareAndset() mixed with normal field
assignment to set?

----
*Josh Humphries*
Manager, Shared Systems  |  Platform Engineering
Atlanta, GA  |  678-400-4867
*Square* (www.squareup.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141208/29d319a7/attachment.html>


More information about the Concurrency-interest mailing list