[concurrency-interest] Semantics of compareAndSwapX
dl at cs.oswego.edu
Thu Feb 20 19:09:03 EST 2014
On 02/20/2014 05:35 PM, David Holmes wrote:
> Andrew Haley writes:
>> On 02/20/2014 10:25 AM, David Holmes wrote:
>>> The volatile-read followed by volatile-write implicit in the
>> CAS precludes
>>> any accesses before the cas appearing after, or vice-versa. I
>> would appeal
>>> intuitively to "roach motel" semantics but Aleksey would jump on me. ;-)
>> True enough, but that does not preclude, say, a write access to am
>> unrelated location appearing after the volatile read but before the
>> volatile write. Does that matter? I guess it must not, but it does
>> mean that the CAS may not be strictly atomic.
> You raise an interesting point here. If your CAS is actually implemented
> using ll/sc and your code has:
> cmpxchg(a, oldval, newval);
> x = 42;
> then the "x=42" seems allowed to move between the ll and sc. Does that
> matter? I don't see how.
As currently spec'ed (in javadoc, outside of the JMM that doesn't
cover CAS), it is clearly allowed, since the volatile load and
store specs are independently met. I don't see any reason
this would change in any possible JMM updates.
> If there was a conditional involved it would matter:
> if (cmpxchg(a, oldval, newval))
> x = 42;
> but then the control dependency should ensure that even a speculative store
> does not escape. But I'm less clear on exactly what the JMM would say.
> Perhaps we do need to say more about the atomicity of CAS with regard to the
> associated volatile actions.
> In the VM we require that CAS is implemented with a full fence.
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest