[concurrency-interest] question about spec for AtomicIntegerFieldUpdater

Doug Lea dl at cs.oswego.edu
Mon Dec 8 09:47:15 EST 2014

On 12/08/2014 09:15 AM, Josh Humphries 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.

This disclaimer arose to cover mappings to processors that
do not have atomic stores of widths corresponding to atomic
CAS APIs, in which case a lock-based scheme must be used across
both set and CAS. Officially, you need to use
FieldUpdater.set(val) if you use CAS, so that the
set can be intercepted on platforms requiring it.

However, all hotspot-targeted processors have at least 32bit
atomic set and CAS, so j.u.c and other internal JDK code
have always been lax about this for ints. But there is still
at least one supported processor (Power32) that needs this treatment
for 64bit longs, so you still see explicit use internally
(for example AbstractQueuedLongSynchronizer.setState.)


More information about the Concurrency-interest mailing list