Re: Arm ldaxr / stxr loop question

On 11/1/2024 9:17 AM, aph@littlepinkcloud.invalid wrote:

jseigh <jseigh_es00@xemaps.com> wrote:

So if were to implement a spinlock using the above instructions
something along the lines of
>
.L0
        ldaxr    -- load lockword exclusive w/ acquire membar
        cmp      -- compare to zero
        bne  .LO -- loop if currently locked
         stxr     -- store 1
         cbnz .LO -- retry if stxr failed
>
The "lock" operation has memory order acquire semantics and
we see that in part in the ldaxr but the store isn't part
of that.  We could append an additional acquire memory barrier
but would that be necessary.

 After the store exclusive, you mean? No, it would not be necessary.

Ahhhh! I just learned something about ARM right here. I am so used to the acquire membar being placed _after_ the atomic logic that locks the spinlock.
 >> .L0
 >>         ldaxr    -- load lockword exclusive w/ acquire membar
 >>         cmp      -- compare to zero
 >>         bne  .LO -- loop if currently locked
 >>          stxr     -- store 1
 >>          cbnz .LO -- retry if stxr failed
So this acts just like a SPARC style:
atomically_lock_spinlock();
membar #LoadStore | #LoadLoad
right?

 

This should be analogous to rmw atomics like CAS but
I've no idea what the internal hardware implementations
are.  Though on platforms without CAS the C11 atomics
are implemented with LD/SC logic.
>
Is this sort of what's going on or is the explicit
acquire memory barrier still needed?

 All of the implementations of things like POSIX mutexes I've seen on
AArch64 use acquire alone.