[cpp-threads] Failed compare-and-swap

[Chris Thomasson]

----- Original Message ----- 
From: "Herb Sutter" <hsutter at microsoft.com>
To: "Chris Thomasson" <cristom at comcast.net>; "C++ threads standardisation" 
<cpp-threads at decadentplace.org.uk>
Sent: Monday, July 30, 2007 1:12 PM
Subject: RE: [cpp-threads] Failed compare-and-swap


>> > Lawrence Crowl wrote:
>> >> Are the synchronization semantics of a failed compare-and-swap
>> >> any different from those of a successful one?

Peter Dimov wrote:
>> > I think that a failed CAS should not be required to perform any
>> > memory synchronization.

Chris Thomasson wrote:
>> Makes sense.

> Yes. Successful CAS == full fence, right?

In the context of the documentation for InterlockedCompareExchange, yes. 
Otherwise you going to get semantics equal to the particular function you 
called. For instance, InterlockedCompareExchangeAcquire will give you 
acquire semantics on success; not full fence. The documentation is not very 
clear on what it does in case of failure...



> Although, there is a lot of win32 code out there that
> uses the return value of a failed InterlockedCompareExchange...

> Yes, but I think that should be separate from Lawrence's question about 
> what a CAS should do in principle.

Okay.


> In the context of coming up with a proposed new memory model across our 
> platforms, one of the things I
> still need to do is review all the existing sync APIs, including 
> Interlocked*, _ReadBarrier, etc. Of course
> they'll continue to be supported (breaking code is not an option), but it 
> might be right to provide
> new/improved replacements and encourage people to use some of the older 
> ones.

> Humm... If Microsoft changes this behavior, it will render all
> that code into a massive fuc%ing race-condition.

> Right, that would be untenable. There's a high compatibility bar, given 
> that it's documented as a full fence
> (see http://msdn2.microsoft.com/en-us/library/ms683560.aspx), so some 
> programs just throw an Interlocked
> operation in as a (deficient) way to spell MemoryBarrier.

> Besides using Interlocked* as a way to spell a full barrier, what cases do 
> you know of where people look at
> the return value? I haven't looked at this issue yet, and I would be 
> interested in understand such cases
> better.

Here are two examples:

http://groups.google.com/group/comp.programming.threads/msg/b6a4eec6cbba625b
(contrived example)


http://groups.google.com/group/comp.programming.threads/msg/57a691b2159fa698
http://groups.google.com/group/comp.programming.threads/msg/31803c3398658e06
(less contrived example; examine the 'initFreeQueue' function)


I think the reasoning is that the InterlockedCompareExchangePointer does 
return real data. In a sense a pointer returned from that function points to 
real data indeed... So, if the user is getting pointers returned from failed 
CAS, well, he might think of neat ways to use that pointer on the failure 
case... Humm.. This could be dangerous indeed. Need to think some more on 
this issue.