[cpp-threads] Failed compare-and-swap

[Peter Dimov]

Paul E. McKenney wrote:

> Sounds like we need to make sure that we should either define CAS to
> have two modes of "success", or to get CAS to explicitly state
> otherwise should it ever be added to ISO/IEC 9945.  Might be nice to
> get the pthread_mutex_trylock() primitive to be added to the list of
> "explicitly stated otherwise" primitives, but that doesn't sound like
> a short-term project.  ;-)

I don't really understand the motivation to make code slower without solving 
a practical problem. I could see some rationale for giving the acquire CAS 
acquire semantics in the failure case (even though it still may penalize 
code that doesn't need the synchronization), but for a trylock? A failed 
trylock did not acquire the lock - pun intended and significant - so you 
can't access the shared state without a data race; why do you need the 
acquire semantics in this case?