[concurrency-interest] The very best CAS loop
peter.levart at gmail.com
Tue Sep 27 10:39:45 EDT 2016
On 09/27/2016 02:56 PM, Andrew Haley wrote:
> On 27/09/16 11:44, Peter Levart wrote:
>> What I was hoping to measure with the benchmark is some difference
>> between using weak CAS and strong CAS in a getAndUpdate retry loop
>> that always invokes the update function (even on spurious failures
>> of weak CAS).
> That's going to be very difficult. In practice truly spurious
> failures are rare enough that you won't see them unless you have false
And that's exactly what my benchmark tries to provoke. It uses CAS to
concurrently update two distinct locations from two distinct threads (no
data contention) with a common cache-line. I was trying to measure the
worst case impact of re-invoking the update function on spurious failure
of weak CAS vs. using strong CAS that would never fail in my benchmark
(as it is strong), as a function of the update function execution time.
But it appears there is no difference on Oracle's arm32 no matter how
long the update function executes.
> (In which case, of course, strong CAS slows down too.) You
> benefit from using weak CAS at times of high contention by not
> spinning to retry a SC which is going to fail anyway.
>> I can understand that this is not possible on x86_64 as both are
>> mapped to the same strong CAS intrinsic. But I also haven't observed
>> any meaningful difference on arm32. So is it possible that Oracle's
>> JDK 9 b137 for arm32 also maps both weak and strong CAS to the same
>> implementation which is a strong CAS simulation?
> Certainly. The only way to be enlightened is to look at the generated
>> Is there any platform where weak CAS is actually a weak CAS
Ah. I don't have any device for that (yet) ;-)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest