Arm64: ldxr / stxr and ldaxr / stlxr

On IOS, there are two similar functions, osatomicadd32 and osatomicadd32barrier I want to know when you need the barrier variant

After removal, they are:

_OSAtomicAdd32:
ldxr    w8,[x1]
add     w8,w8,w0
stxr    w9,[x1]
cbnz    w9,_OSAtomicAdd32
mov     x0,x8
ret     lr

_OSAtomicAdd32Barrier:
ldaxr   w8,w0
stlxr   w9,_OSAtomicAdd32Barrier
mov     x0,x8
ret     lr

In which case do you need the load acquire / store release semantics of the latter? Can ldxr / stxr instructions be reordered? If so, is it possible to "lose" atomic updates without obstacles? From what I have read, it seems that this will not happen. If it is true, why do you need the barrier variant? Maybe only you happen to need DMB for other purposes?

thank you!

Solution

Osatomicaddad32barrier() is suitable for those who use osatomicadd() to do more than atomic increment Specifically, they are implementing their own multiprocessing synchronization primitives based on osatomicadd() For example, create your own mutex library Osatomicaddad32barrier() uses heavy barrier instructions to force memory sorting on both sides of atomic operations This is undesirable in normal use

To sum up:

1) If you only want to increment integers in a thread safe manner, use osatomicadd32()

2) If you encounter a pile of old code that foolishly thinks osatomicadd32() can be used as a processor memory sorting and speculation barrier, replace it with osatomicadd32barrier()