[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Thomas Hawtin tackline at tackline.plus.com
Mon May 29 14:50:41 EDT 2006


Jeremy Manson wrote:
> 
> More worrisome is the fact that there isn't really any meaningful use 
> case for a happens-before-free weakCompareAndSet on an AtomicReference 
> (AFAICT).  So do you end up keeping hb for AtomicReference, but losing 
> it for AtomicInteger?  Is that a consistent API?

It makes sense for referred objects that have been created to be
thread-safe, or the referrer is just interested in identity.

Trawling through the Java library to find meaningful use cases for
AtomicReference/AtomicReferenceFieldUpdater.weakCompareAndSet....


java.io.BufferedInputStream. The only point of the CAS is for the stream
closing case. weakCAS could be tried before the CAS.


java.util.concurrent.ConcurrentLinkedQueue. It looks as if some of the
CAS could be made weak. All Node fields are volatile. There needs to
always be one happens-before edge between enqueing and removal, but
possibly not as many. Here and elsewhere, CASing to null, I guess could
be weak (in a loop). Perhaps there should be a remove() with volatile
read (but not write) happens-before semantics in AtomicReference. OTOH, 
looking getAndSet(,null) adding an extra loop will presumably not help.


java.lang.System.getSecurityManager. We could possibly avoid the
volatile read in common case with something like:

     public static SecurityManager getSecurityManager() {
	if (security.weakCompareAndSet(null, null)) {
              return null;
         } else {
              return security.get();
         }
     }
or
     public static SecurityManager getSecurityManager() {
         SecurityManager securityNV = System.securityNV;
	if (security.weakCompareAndSet(securityNV, securityNV)) {
              return securityNV;
         } else {
              securityNV = security.get();
              System.securityNV = securityNV;
              return securityNV;
         }
     }

A weakGet would suffice in this situation, if it existed. Of course this
code would be must slower with the current quality of implementation.


Tom Hawtin



More information about the Concurrency-interest mailing list