[concurrency-interest] AtomicReferenceweakCompareAndSet "Mayfailspuriously"?

Hans Boehm Hans.Boehm at hp.com
Tue May 30 01:16:41 EDT 2006

Something like Bill's changes to the javadoc would be a great idea.

I still don't like the idea of giving weakCompareAndSet different
semantics in different classes.  In fact, I think I like it less and less
the more we explore this.

The other issue that we discussed a bit in a side conversation is that
there is no way to start with weakCompareAndSwap, and "add" volatile
semantics to either the read and/or the write, without going all the way
to compareAndSwap, and eliminating the possibility of spurious failure as
well.  This again leads me to conclude that weakCompareAndSwap currently
has very limited applicability.  But I think we also agree that any
attempt to improve matters ends up with a wider interface to support some
rather esoteric programs.


On Mon, 29 May 2006, Bill Pugh wrote:

> On May 29, 2006, at 12:49 AM, Brian Goetz wrote:
> >> What Cliff wants is an atomic integer for use with counters that
> >> is not
> >> volatile, so that the extra memory barriers required for violatile
> >> semantics
> >> can be elided. This gives rise to a large performance boost in the
> >> context
> >> Cliff wants to use it - performance counters. Cliff can use
> >> weakCAS for this
> >> purpose.
> >
> > The behavior Cliff wants is analogous to the meaning of volatile in
> > the
> > old memory model, where volatile wasn't required to ensure the
> > visibility of any value other than the variable being written/read.
> >
> > I think what bothers Bill about the proposal (I am confident Bill will
> > correct me if I am wrong) is that there is no way to represent the old
> > volatile semantics in the new memory model, and therefore there
> > would be
> > no mathematical basis for the proposed semantics of wCAS.
> No, actually, I'm not worried about that.
> The way it is described in the current JavaDoc isn't correct,
> but the memory model has no problem with synchronization actions that
> don't establish happens-before ordering. We can fix the JavaDoc.
> My worry is that people using weakCompareAndSet will accidently
> introduce
> a synchronization error into their program.
> In particular, I think the use case for a
> weakCompareAndSetWithoutHappensBefore
> on a AtomicReference is rather limited.
> Consider:
>    Thread 1 uses a weakCompareAndSet to store a reference to an
> object X into
>    an AtomicReference
>    Thread 2 uses a get on the AtomicReference to get a reference to
> X. However,
> there is no happens-before ordering from the CAS in thread 1 to the
> get in thread 2.
> Thus, if thread 1 constructed X, or performed any updates to X before
> performing
> the CAS, then there would be a data race if thread 2 tried to read
> any of the fields of X,
> and the reads wouldn't be guaranteed to see any of the updates to the
> fields of X
> performed by thread 1.
>    Doug, and perhaps 3 other people in the world, could figure out
> valid and useful
> use cases for a weakCompareAndSet on an AtomicReference that didn't
> create happens-before
> orderings.
> By the way, one of the things that should be added to
> java.util.concurrent in Java 7 is a
> ConcurrentCounter: somethings you can increment quickly, but for
> which reading a value
> is more expensive. There are all sorts of games you could play here,
> such as using
> thread locals.
> Suggested JavaDoc for weakCompareAndSet:
>      Atomically sets the value to the given updated value if the
> current value == the expected value.
> May fail spuriously. Unlike compareAndSet(), and other operations on
> an AtomicX, the weakCompareAndSet()
> operation does not create any happens-before orderings.  Thus, just
> because a thread sees an update to an AtomicX caused
> by a weakCompareAndSet doesn't mean it is properly synchronized
> with operations that occurred before the weakCompareAndSet(). You
> probably don't want to use this method, but instead
> should just use compareAndSet;
> as there are few cases where weakCompareAndSet is faster than
> compareAndSet, and there are a number of cases in which
> trying to optimizing your code by using weakCompareAndSet rather than
> compareAndSet will introduce subtle and hard to
> reproduce synchronization errors into your code.
> Bill
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list