[jmm-dev] weakCompareAndSet memory semantics

[Andrew Haley]

On 04/21/2016 01:10 PM, David Holmes wrote:
> How are you busting the doors if you get a _spurious_ failure? It means 
> something unrelated directly to your CAS (so your value is not stale!) 
> happened.

Although the architecture doesn't define it, the usual reasons that an
exclusive store fails are the value is contended or your thread was
interrupted.  In either case your value may be stale, in which case
you want to read it again: there's no point retrying the CAS in order
to find out which it was.

> The spurious failures from ll/sc are a result of implementation
> constraints so it has never made sense to me to have that exposed at
> a higher level. On the contrary many CAS-based algorithms expect
> that failure indicates some other thread made progress.

Sure, and those algorithms can spin.  The point about ll/sc is that
you have a choice.  CAS is much more restrictive than ll/sc.

Andrew.