RFR(xs): 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7

[David Holmes]

On 6/10/2018 12:18 AM, Andrew Haley wrote:
> On 10/05/2018 02:40 PM, Severin Gehwolf wrote:
>>> Also I thought that if ldrex was not paired with a strex then you should
>>> at least issue clrex - as done in generate_atomic_load_long() in
>>> stubGenerator_arm.cpp
>>
>> I'll defer to Andrew Haley for this.
> 
> I'm skeptical that CLREX is necessary. The classic CAS for Arm is
> 
>      MOV  R1, #0xFF             ; load the ?lock taken? value
> try LDREX    R0, [LockAddr]    ; load the lock value
>      CMP R0,  #0                ; is the lock free?
>      STREXEQ  R1, R0, [LockAddr]; try and claim the lock
>      CMPEQ R0, #0               ; did this succeed?
>      BNE try                    ; no ? try again. . .
> ; yes ? we have the lock
> 
> There's no CLREX, and no-one ever reported any problem. CLREX could be
> a performance boost because it takes the cache line out of exclusive
> state back to shared state, reducing later bus traffic.

I would see CLREX as a potential performance boost not something needed 
for correctness. But you're right that failure paths from typical CAS 
code won't execute the strex and don't include a clrex.

David