[cpp-threads] D2335 (sequential consistency proof) revision

[Chris Thomasson]

----- Original Message ----- 
From: "Herb Sutter" <hsutter at microsoft.com>
To: "C++ threads standardisation" <cpp-threads at decadentplace.org.uk>
Cc: "Howard Hinnant" <howard.hinnant at gmail.com>
Sent: Thursday, August 23, 2007 4:50 PM
Subject: Re: [cpp-threads] D2335 (sequential consistency proof) revision


> Lawrence wrote:
>> It seems to me that the approach we would with CAS should also apply
>> to locks.
>
> But CAS and lock() are different operations. CAS is low-level and can be 
> used for
> reading as well as writing (well, it necessarily is about writing) hence 
> needs both
> acquire and release in the success case at least. But taking a lock begins 
> a critical
> section and so is only an acquire operation. No?
>
> >> That is, without decoration they are SC, not just acquire
> >> or release.
>
> > Why should taking a lock be a full fence? The only use case I know of 
> > for making a
> lock operation a full fence is the anti-idiom of abusing a trylock or 
> timed lock to detect > a lock taken by another thread, as Hans noted 
> below.
>
> I thought that taking a lock enters a critical section, which only needs 
> to be an
> acquire.

[...]

Taking a lock does not necessarily require a #StoreLoad | #StoreStore 
barrier. There are asymmetric locking algorithms in which certain thread(s) 
can take the lock without using interlocked rmw or store/load memory barrier 
instructions.