[jmm-dev] weakCompareAndSet memory semantics

[David Holmes]

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

David
-----

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