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

Gregg Wonderly gregg at cytetech.com
Fri Apr 16 13:30:17 EDT 2010

I sent this earlier and apparently only replied to David...  I changed some 
wording to try and be clearer.

I agree with David, that the use of names which include the keywords that 
developers are already learning the meaning/use of would be helpful.  I also 
concur that in many cases, there may be bugs created by misuse just for the sake 
of speed, or because they are copying code from somewhere else and using it 

I'd think that a subclass, which completely encompasses the "asIfFinal" or 
"nonVolatile" etc aspects of use would be an improvement because it would 
provide a place for "reading javadoc" about why you might choose to use the 
class.  The subclass could also guarantee that the "visible" behavior was no 
"better" than the class was documented to provide.  I say "better" in the sense 
that putting these methods in AtomicInteger, for example, means that all the 
"set" and "get" functions are available.  I'd guess that you would not want 
results from the other methods that would produce differing or dissimilar 

It seems that's where the bugs would start to appear because one branch of 
existing code is using appropriate methods correctly and some new code is not, 
and occasionally visibility if fixed by one branch, while the other occasionally 
misses a value because of a data race for example.

I'm wondering if subclass names which have to do with specific use cases such as 
"AtomicIntWithReadAsIfFinalAndWriteAsIfVolatile" etc. are useful?

Gregg Wonderly

David Holmes wrote:
 > 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.
 > Cheers,
 > David
 >> -----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
 > _______________________________________________
 > 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