[concurrency-interest] AtomicReferenceFieldUpdater - methods set, get, compareAndSet semantics
davidcholmes at aapt.net.au
Wed Dec 7 07:00:36 EST 2011
The user is correct. On implementations that require locks, none of the
field updater classes can guarantee atomicity except with regards to other
methods of the field updater.
In practice I'm only aware of AtomicLongFieldUpdater actually having a
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ruslan
> Sent: Wednesday, 7 December 2011 8:57 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] AtomicReferenceFieldUpdater - methods
> set,get, compareAndSet semantics
> 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?
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest