[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Jeremy Manson jmanson at cs.purdue.edu
Mon May 29 11:08:26 EDT 2006

I'm probably being dim, but why don't you need the happens-before 
relationship here between the setter and a subsequent getter?  It seems 
to me that you need the release on fixedNext...  No?


Doug Lea wrote:
> 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).  
> No common ones, but as we've seen, use cases for weakCAS
> aren't all that common to begin with. One use case is in
> help-out steps of wait-free algorithms, of the form:
> retry:
>   read-volatile n = head.get();
>   read-volatile next = n.next.get();
>   if (inconsistent(next)) {
>        n.next.weakCompareAndSet(next, fixednext);
>        goto retry;
>   }
>   ...
> Because of full retry, and the likelihood that a retry by itself
> will suffice (i.e., probably some other thread has already fixed
> link), you might as well use the cheapest form. (Or maybe not,
> depending on the relative likelihoods. It's an empirical issue though.)
> Among others, Michael-Scott queues have steps of this basic form,
> although the j.u.c ConcurrentLinkedQueue version use strong CAS in this
> sort of case. It could be changed a bit to use weak though.
> Aside: It might be nice if there were javadoc tags saying
> "you probably {do, don't} want to use this method".  For the
> sake of completeness, many APIs have methods that are only
> rarely needed. But indispensible when they are needed.
> -Doug

More information about the Concurrency-interest mailing list