On Thu, Jun 30, 2016 at 4:19 AM, Doug Lea <d...@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.
