[concurrency-interest] question about spec for AtomicIntegerFieldUpdater

Vitaly Davidovich vitalyd at gmail.com
Mon Dec 8 10:05:08 EST 2014


I think it's trying to highlight the fact that atomic classes wrap their
underlying primitive and control all access to it (I.e all accesses are
through the atomic class).  With the updater, other code may be accessing
the same primitive "naked" and thus it can't promise the same thing unless
all access to that variable is done through the updater.  For example, some
uses of the underlying field directly may involve a test-then-act sequence
or some other multi step process (I.e. not atomic).

Sent from my phone
On Dec 8, 2014 9:46 AM, "Josh Humphries" <jh at squareup.com> wrote:

> 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)
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141208/e3643d47/attachment.html>


More information about the Concurrency-interest mailing list