[concurrency-interest] Semantics of compareAndSwapX

Andrew Haley aph at redhat.com
Wed Feb 26 06:22:43 EST 2014


On 02/26/2014 03:18 AM, Hans Boehm wrote:
> I think that's completely uncontroversial.  ARMv8 load acquire and store
> release are believed to suffice for Java volatile loads and stores
> respectively.

No, that's not enough: we emit a StoreLoad barrier after each volatile store
or before each volatile load.

> Even the fence-less implementation used a release store
> exclusive.  Unless I'm missing something, examples like this should be
> handled correctly by all proposed implementations, whether or not fences
> are added.
> 
> As far as I can tell, the only use case that require the fences to be added
> are essentially abuses of CAS as a fence.

Well, yes, which is my question: is abusing CAS as a fence supposed to work?

Andrew.



More information about the Concurrency-interest mailing list