[cpp-threads] Failed compare-and-swap

[Boehm, Hans]

> From:  Herb Sutter
> 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?
On second thought, I think I want to to withdraw the parenthetical
comment.  The value being updated by the CAS might be boolean.  But
since we allow a CAS to fail spuriously, failure doesn't really tell you
anything about the original value.  (If we disallowed spurious failure,
then failure would indicate that the atomic did not have the given
value, which would have to count as a successful read.)
> 
> > 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.

I agree.  That sounds right to me.

FWIW, java.lang.concurrent.atomic.compareAndSet returns only a Boolean.
But (unlike weakCompareAndSet) it may not fail spuriously, and hence I
think still needs acquire semantics in the failure case to provide
sequential consistency for race-free programs.

For the general version, I think the viable options are:

1. Have the failure case satisfy the same constraints as the success
case (except that release semantics become vacuous).
2. Drop the read value from the interface, matching the Java interface.
This would also make the acquire semantics vacuous in the failure case.
3. Have acq_rel and acquire, but definitely not seq_cst, drop the
acquire ordering constraint on failure.
4. Supply two separate ordering constraints.

After reconsidering all the implications, I could tolerate any of these,
but I'd personAlly go for either option 1 or 2.  Option 3 strikes me as
particularly baroque.

Hans

> 
> Herb
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>