Re: Are there real use cases with the Java access modes?

On 7/17/21 6:09 PM, Alex Otenko via Concurrency-interest wrote:
> I think one important case is an atomic increment that does not 
> introduce full barriers (choose opaque, if you are just counting; 
> acquire, if you are acquiring a semaphore; release, when releasing; or 
> rel-acquire). I know of a few like things achievable in other 
> languages, which probably are beneficial on many non-tso architectures.

I agree that there is a case for adding weaker "RMW" methods 
getAndAddOpaque, getAndSetOpaque, getAndBitwiseAndOpaque, and 
getAndBitwiseOrOpaque. There are now processors that support this 
directly, and others can fall back to heavier variants.  And usage can 
speed up some operations on some processors enough to be worthwhile. 
I'll look into it.

>
> Another important clarification needed is what barriers are enforced 
> on failure of CAS. I think there was a discussion about this on this 
> list, but I don't recall if that resulted in a definitive answer about 
> what it should be.

I don't think there is any ambiguity in the spec (because it doesn't 
distinguish the cases). Variants that allow weaker ordering on CAS 
failure were triaged out mainly because they would cause an API 
explosion: Up to 16 (vs 4) versions each of compareAndSet, 
weakCompareAndSet, without compelling use cases.

-Doug


_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest