[concurrency-interest] Extended access methods for Atomics (and AQS)

Doug Lea dl at cs.oswego.edu
Wed Apr 14 08:52:46 EDT 2010

Last fall, we tabled discussion of the proposed Fences API.
But regardless of the outcome of and future discussions when
we re-raise it, there seemed to be consensus that at the very
least, we should extend the methods of Atomic classes to support
the various memory effect modes that you otherwise would need
Fences methods to obtain.

I'm finally trying this out. A draft update of AtomicInteger
with these changes is at:
(For now, only class AtomicInteger). Ignoring the arithmetic methods
(getAndAdd etc), the API looks like (with "*" in front of
the added methods)

"volatile-write" mode
    void set(int v)
    boolean compareAndSet(int e, int v);
    int setAndGet(int v);

store-ordered (aka release, pseudo-final-field) mode
*  void setInStoreOrder(int v);
*  boolean compareAndSetInStoreOrder(int e, int v);
    void lazySet(int v) // synonym for setInStoreOrder

load-ordered (aka volatile-read, acquire) mode
    int get();
*  compareAndSetAndGet(int e, int v);

relaxed-order (aka non-volatile) mode
*  int getInRelaxedOrder();
*  void setInRelaxedOrder(int v);
    boolean weakCompareAndSet(int e, int v);

Comments and suggestions about method names and
semantics would be very welcome. (Notice that
the naming scheme denigrates "lazySet", a name
that no one likes!)

The form of these methods is roughly similar to
C++0x modes (at least the ones supportable in Java),
but avoids the sometimes-controversial terms
"acquire" and "release" in mode/method names.

For now, the specs are just done informally. Assuming we
go ahead with this, we'd adapt the more formal versions done
in Fences drafts and place them in j.u.c.atomic package docs
to spell out better.

Versions for other stand-alone Atomic objects (AtomicLong,
AtomicReference) would be equally straightforward. As always, the
main problems lie in the FieldUpdater forms, which are sadly
also the most useful. The dynamic type checking overhead
required for these forms is often more expensive than
any savings you get from weaker access modes. (This is
why Fences versions continue to be attractive.) However,
for uniformity, extended methods in these would also be
supported. Similarly for the Atomic*Array classes.
And it is still conceivable that new JVM mechanics being put
into place for JSR292 might be used to reduce overhead.

One further accommodation is that the encapsulated int
state value inside AbstractQueuedSynchronizer should also
support at least the setInStoreOrder method (none of
the other new methods seem to ever apply). Similarly
for AbstractQueuedLongSynchronizer. Using this as
appropriate speeds up ReentrantLock by 5% - 20%, so
is a good idea regardless of all other changes.


More information about the Concurrency-interest mailing list