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

David Holmes davidcholmes at aapt.net.au
Wed Apr 14 19:49:35 EDT 2010

Hi Doug,

I think "InStoreorder" and "InRelaxedOrder" could easily be misunderstood as
relating to "total store ordering", or "relaxed memory models" or any
particular architecural memory model that uses that kind of terminology.

If "InStoreOrder" means "with memory effects equivalent to setting a final
variable" then lets just say that:

   setAsIfFinal(int newVal)

and similarly:

   setAsNonVolatile(int newVal)

I guess this is somewhat better than Fences in that the semantics of the
methods are easier to understand. But these are still methods that the vast
majority of programmers won't know when it is valid to use them. They will
only discover that they seem faster and so use them regardless :( Can we not
"hide" them a bit better eg:

  class DontUseMeUnlessYouKnowWhatYouAreDoingAtomicInteger extends
AtomicInteger {
      public void setAsNonVolatile(int newVal) { ... }

or a utility class

  class DontUseMeUnlessYouKnowWhatYouAreDoingAtomicHelper {
     static void setAsNonVolatile(AtomicInteger x, int newVal) { ... }

> One further accommodation is that the encapsulated int
> state value inside AbstractQueuedSynchronizer should also
> support at least the setInStoreOrder method

I fear the chance of misuse greatly outweighs any performance benefit.

Aside: if I ever see a bug report involving these new methods my response
will be to request the submitter to rewrite their program using the "proper"
methods. Without tools or formalisms to establish correctness of use these
methods will in many cases just be bugs waiting to happen.


> -----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, 14 April 2010 10:53 PM
> 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/concurrent/
> 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