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

[dean.long at oracle.com]

On 10/5/18 5:18 PM, David Holmes wrote:
> 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.
>

I think it's needed for correctness only at context-switch time.  If you 
context switch after the LDREX, you don't want the exclusive state to 
remain for the next thread scheduled.

dl

> David