[concurrency-interest] Semantics of compareAndSwapX
oleksandr.otenko at oracle.com
Mon Feb 24 09:47:23 EST 2014
Can someone clarify this issue? I don't know ARM instructions, yet it
seems the discussion contradicts itself.
This here observation summarizes that "GCC's usage of ....<instruction
sequence> is ok" despite it not being a full barrier, and that the
reordering of memop_A and memop_C before and after CAS respectively, is
Yet further in the discussion Doug mentions it is meant to be a volatile
read+volatile write, which would preclude the reordering of memop_A and
So, is that reordering allowed or not?
On 20/02/2014 09:48, Andrew Haley wrote:
> On 02/19/2014 08:40 PM, Stephan Diestelhorst wrote:
>> On 18 February 2014 12:56, Andrew Haley <aph at redhat.com> wrote:
>>> On 02/14/2014 01:51 PM, Stephan Diestelhorst wrote:
>>>> I am currently following up inside ARM about this, stay tuned.
>>> Any news?
>> Yes, so my original understanding was too simplistic. In the
>> sequence of memop_A; ldx.acq(B) ;... ; stx.rel(B); memopp_C we may
>> indeed observe a lack of ordering between memop_A and memop_C. So
>> the instruction sequence is not meant to be a full-fence
>> replacement. This is, however, consistent with our manuals, and the
>> implementation of the C++11 atomics, and the notion of sequential
>> consistency of atomics.
> Thank you.
> So, GCC's usage of ldaxr ... stlxr for CAS is OK, even though it
> doesn't completely enforce a full fence. This is interesting. I
> wonder how anyone (not on the language committee :-) is expected to
> know this. Maybe they're not, and there is going to be some
> interesting confusion when people try to port software from Intel to
>> So it really boils down to the semantics of Unsafe.CAS and that was
>> what you were asking earlier.
> OK, thanks. Thought so.
> So, Back to you, Doug: what are the semantics of Unsafe.CAS ?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest