[jmm-dev] weakCompareAndSet memory semantics

[Andrew Haley]

On 22/04/16 00:38, David Holmes wrote:
> On 21/04/2016 10:51 PM, Andrew Haley wrote:
>> 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.
> 
> Not aware of the "interrupted" case though I don't see how that would 
> make the value stale.

It makes the value old; the value is therefore more likely to be stale.

> More general case is that there was an unrelated store into the same
> "region" of memory - again this doesn't make your value stale.

OK, that's another possibility.  But a store exclusive failure caused
by false sharing involves a delay, so the value is older, and again
more likely to be stale.  Also, I am assuming that anyone with enough
expertise to use a weak CAS also has enough sense to try to prevent
false sharing.

> Now obviously if there is high contention on the variable you are
> cas'ing then your value might be stale by the time you re-loop for
> the spurious failure, but that is a different scenario - and if
> contention is that high you are going to have issues regardless.

In what sense is it a different scenario?  If contention is low then
it really doesn't much matter what you do: the CAS will usually sail
straight through anyway.

Andrew.