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

Bryan Thompson bryan at systap.com
Wed Apr 14 10:55:00 EDT 2010


What about eventually consistent increment() and add() methods which do not rely on CAS operations and are thus not subject to spins under concurrent requests?  There are plenty of use cases where all I want is to increment a counter and the atomicity of the operation is not required, just the guarantee that the counter will (eventually) reflect all increment() and decrement() requests.


> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu 
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf 
> Of Doug Lea
> Sent: Wednesday, April 14, 2010 8:53 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Extended access methods for 
> Atomics (and AQS)
> 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:
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurr
> ent/atomic/AtomicInteger.html
> (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.
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list