[jmm-dev] weakCompareAndSet memory semantics

[Andrew Haley]

On 04/22/2016 01:45 PM, David Holmes wrote:
> On 22/04/2016 10:03 PM, Andrew Haley wrote:
>> On 04/22/2016 12:32 PM, David Holmes wrote:
>>> 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!
>>
>> Potentially?  Maybe that would be true if spurious store exclusive
>> failures were common, but they aren't.
> 
> If they aren't common you neither gain nor lose - so no motivation to 
> use weakCAS.

No, that is not right.  See below.

>>> 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.
>>
>> I just did 10^9 uncontended ldx/stx on my system here.  Guess how many
>> spurious failures there were?  Zero.  This is a tool for people who
>> know what they're doing.
> 
> I don't get your point. You could also write code that gets many 
> spurious failures.

Only by doing something really stupid like false sharing.

> We are saying "use weakCAS on ll/sc because it will be better if there 
> are spurious failures".

That's not what it's about at all.  It's about not retrying if the
store exclusive fails.  Except in the pathological case of false
sharing, store exclusive failures probably aren't spurious.  It's just
that the caller gets to decide what to do if the store fails.

Andrew.