[concurrency-interest] Semantics of compareAndSwapX

Doug Lea dl at cs.oswego.edu
Wed Feb 26 07:24:57 EST 2014

On 02/26/2014 06:22 AM, Andrew Haley wrote:
> 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?

Because plain CAS has volatile store semantics, you need to apply the
same reasoning in fence placement (above) as for volatile stores.


More information about the Concurrency-interest mailing list