[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater
dl at cs.oswego.edu
Thu Sep 21 08:26:53 EDT 2017
On 09/20/2017 09:31 PM, Carl Mastrangelo wrote:
> I still don't understand. I have included a copy of the javadoc I am
> 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 only with respect to other
> invocations of |compareAndSet| and |set| on the same updater.
> So here is my reasoning:
> 1. Modifications of a variable using the updater are atomic if and only
> if using set() or compareAndSet()
> 2. Volatile variable initialization is not done using the set() or
> 3. Therefore, compareAndSet is not atomic.
> The conclusion seems absurd, but follows the javadoc. What am I missing?
The disclaimer was initially introduced (late in Java 1.5 development)
because of a few seldom-used, now-obsolete processors (Power5, some Via
chips) without a CAS-like operation as wide as the corresponding
bitwise-atomic write. It is obviously a crummy state of affairs,
in that practically no one ever needed to pay attention to the
disclaimer (but was there just in case), and it does not apply to
any current platforms. It does not appear in VarHandle specs (that
normally replace FieldUpdaters anyway). Since the disclaimer will never
be needed again (no processor designed after the year 2000 or so would
do this), it should be removed. (It also has no impact on j.u.c
internals, since they all use VarHandles instead of FieldUpdaters).
More information about the Concurrency-interest