[cpp-threads] Failed compare-and-swap

[Herb Sutter]

> > 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?

> 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. 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.

Herb