Semantics of VarHandle CAS methods

[Martin Buchholz]

On Thu, Jun 30, 2016 at 4:19 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 06/30/2016 06:38 AM, Martin Buchholz wrote:
>
>> It's not only about naming.
>>
>> So yes, I'd like the name weakCompareAndSet to be the sequentially
>> consistent version, BUT I'd also expect the next more relaxed version to
>> be
>> memory_order_acq_rel which we don't provide.
>>
>
> There are a few flavors of C++ CAS/weakCAS that aren't explicitly supported
> (also including those with different memory orders on success and failure),
> because you can get the effects with combinations of the supplied versions
> and
> explicit fences. Supporting all of them would have added lots of
> seldom-used
> methods.
>
>
One concrete proposal that removes a method:

Replace
weakCompareAndSetAcquire and weakCompareAndSetRelease with
weakCompareAndSetAcquireRelease


> I don't have a good intuition about how useful non-sequentially-consistent
>> CASes are.
>>
>
> Among other uses, fallible performance counters, and the bases for
> combining with fences as above.


We can keep the fully relaxed flavor for use with fences, so you can still
get the effect of  weakCompareAndSetAcquire if you really want.

In C++ we have sequential consistency of the single memory location holding
an atomic (cache coherence).  Should we say something about locations
updated via a VarHandle?  If you call weakCompareAndSetAcquire, then the
spec says the write is a "plain write", but some kind of cache coherence
seems inherent in the idea of a compareAndSet, so the write itself has to
be complete and visible.