[cpp-threads] Failed compare-and-swap

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Aug 1 19:03:39 BST 2007


On Wed, Aug 01, 2007 at 10:17:55AM -0700, Herb Sutter wrote:
> I forgot to address one detail of what Hans wrote yesterday:
> 
> I wrote:
> > > Summarizing:
> > >
> > > The point well illustrated by these examples is that if CAS
> > > returns the old value (rather than a bool) it can be used to
> > > perform an atomic load. If we allow that, then it should have
> > > the same default acquire semantics as a load (unless
> > > overridden in the weak/relaxed atomics of course).
> > >
> > > Lawrence and everyone, what do you think? Now that I see
> > > this, it seems obvious in retrospect, and this question must
> > > have come up before with CAS semantics. What do other systems do?
> 
> Hans wrote:
> > I completely agree with this.  If a CAS can be used to read the old
> > value (which it can, arguably if it only has a boolean result),
> 
> Why do you think a failed CAS can be used to read the old value if
> you have a boolean success/fail result?

For the record, the atomic_compare_swap() proposal in N2324 returns
the type of the operand as shown in the "Synopsis" section.  However,
the earlier "Atomic Operations" section says that "compare-and-swap"
returns either true or false.  We probably need to choose.  ;-)

> > and it
> > has at least acquire semantics, then it should still have acquire
> > semantics even if it fails and the write doesn't take place.
> > The read still succeeds.
> 
> It seems like there are two legitimate choices:
> 
>   - CAS returns the old value, in which case a failed CAS should at
> least by default have acquire semantics because it's a read.
> 
>   - CAS returns only a success/fail boolean, in which case a failed
> CAS need not have any ordering semantics.
> 
> Does that make sense? It seems we can happily choose either, but the
> choice affects the return type.

My preference would be returning the old value, but both variants have
been used successfully multiple times.

						Thanx, Paul



More information about the cpp-threads mailing list