[jmm-dev] weakCompareAndSet memory semantics
David M. Lloyd
david.lloyd at redhat.com
Fri Apr 22 13:52:09 UTC 2016
On 04/22/2016 07:45 AM, 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.
>>> 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
>> 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.
> We are saying "use weakCAS on ll/sc because it will be better if there
> are spurious failures".
> But now you are saying you won't get spurious failures anyway.
> So why even bother with weakCAS?
I think it boils down to this: it's likely to be slightly faster in some
situations. If it's not there, someone is going to ask for it, because
they will want that slight bump, and it's in both C++ and C. It seems
trivial to implement. So why *not* have it?
More information about the jmm-dev