[jmm-dev] weakCompareAndSet memory semantics

Paul E. McKenney paulmck at linux.vnet.ibm.com
Fri Apr 22 17:17:26 UTC 2016


On Fri, Apr 22, 2016 at 04:24:48PM +0100, Andrew Haley wrote:
> On 04/22/2016 02:52 PM, David M. Lloyd wrote:
> > I think it boils down to this: it's likely to be slightly faster in some 
> > situations.  If it's not there, someone is going to ask for it, because 
> > they will want that slight bump, and it's in both C++ and C.  It seems 
> > trivial to implement.  So why *not* have it?
> 
> There's also the case where you have a highly-contended counter --
> think profiling -- and you want to increment it, you can't tolerate
> much of a delay.  It's a disaster if that counter goes backwards but
> failing to increment it at a time of high contention is not so bad.
> So you try it once and continue.

Agreed.

For example, you might keep a local counter, so that if the attempt
to increment the global counter does not immediately succeed (for
whatever reason), you increment the local counter.  The next time
around, you attempt to add the local counter to the global one.

In this case, it is not helpful to retry a failed store-conditional,
even if the failure was spurious.

							Thanx, Paul



More information about the jmm-dev mailing list