[jmm-dev] weakCompareAndSet memory semantics

[David Holmes]

On 22/04/2016 6:38 PM, Andrew Haley wrote:
> 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.

I consider it a different scenario because it requires high contention. 
If you have low contention (CAS ideal case) the spurious failures are 
unlikely to make your data stale so jumping back out to the outer loop 
to re-fetch doesn't gain anything - potentially the opposite!

Obviously this all depends on the exact circumstances - but that is why 
I question these blanket statements about weakCAS performing better on 
ll/sc systems. Given we're dealing with WORA Java code this may push 
people towards always using weakCAS just in case they run on a ll/sc system.

Cheers,
David

> Andrew.
>