[cpp-threads] Failed compare-and-swap

[Paul E. McKenney]

On Mon, Jul 30, 2007 at 01:12:09PM -0700, Herb Sutter wrote:
> > > 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?

Successful CAS has the specified memory-ordering properties.  The
strong-atomics CAS would have a full fence when successful.  A given
weak-atomics CAS would have the specified memory-ordering properties,
for example, a relaxed CAS would have no memory-ordering properties.

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

There are algorithms in which a failed CAS plays a role similar to a
failed trylock.  So it would make quite a bit of sense for a failed CAS
to have the same memory-ordering semantics that it would have had if
successful.  After all, the common case should be successful CAS!  ;-)

						Thanx, Paul