[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