[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
>>> 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.
> 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 mailing list