[cpp-threads] Failed compare-and-swap

[Peter Dimov]

Paul E. McKenney wrote:
> On Tue, Jul 31, 2007 at 10:14:17PM +0300, Peter Dimov wrote:
>> 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?
>
> But given C++0x atomics, it -is- possible to access the shared state
> without a data race if the shared state contains atomics.

You can, but since you'll race against the other stores, it's not likely 
that the trylock acquire will buy you much. You can probably put the acquire 
on the first load. Any practical examples?

> And, again, if trylock failure is frequent enough to cause performance
> problems, you likely have other problems.

Maybe. If you expect or need acquire semantics from a failed trylock, you 
likely have other problems. :-)