{"id":106963,"date":"2022-08-11T07:00:00","date_gmt":"2022-08-11T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106963"},"modified":"2022-08-11T07:47:39","modified_gmt":"2022-08-11T14:47:39","slug":"20220811-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220811-00\/?p=106963","title":{"rendered":"The AArch64 processor (aka arm64), part 13: Atomic access"},"content":{"rendered":"

Atomic operations are performed by the traditional RISC-style load locked<\/i>\/store conditional<\/i> pattern.<\/p>\n

    ; load exclusive register byte\r\n    ldxrb   Rd\/zr, [Xn\/sp]\r\n\r\n    ; load exclusive register halfword\r\n    ldxrh   Rd\/zr, [Xn\/sp]\r\n\r\n    ; load exclusive register\r\n    ldxr    Rd\/zr, [Xn\/sp]\r\n\r\n    ; load exclusive register pair\r\n    ldxp    Rd1\/zr, Rd2\/zr, [Xn\/sp]\r\n<\/pre>\n
These instructions atomically load a byte, halfword, word, doubleword, or pair of registers from memory. The instruction also tells the processor to monitor the memory address to see if any other processor writes to that same address, or addresses in the same “exclusive reservation granule”. (Implementations are allowed to have granules as large as 2KB.)<\/p>\n
Note that the atomicity guarantee is only partial if you use LDXP<\/code> to load a pair of 64-bit registers.\u00b9 The entire 128-bit value is not loaded atomically; instead, each 64-bit portion is loaded atomically separately. You can still get tearing between the two registers.<\/p>\n
The only supported addressing mode is register indirect. No offsets or indexes allowed.<\/p>\n
After an exclusive load, you can attempt to store a value back to the same address:<\/p>\n
    ; store exclusive register byte\r\n    stxrb   Rs\/zr, Rt\/zr, [Xn\/sp]\r\n\r\n    ; store exclusive register halfword\r\n    stxrh   Rs\/zr, Rt\/zr, [Xn\/sp]\r\n\r\n    ; store exclusive register\r\n    stxr    Rs\/zr, Rt\/zr, [Xn\/sp]\r\n\r\n    ; store exclusive register pair\r\n    stxp    Rs\/zr, Rt1\/zr, Rt2\/zr, [Xn\/sp]\r\n<\/pre>\n
If the reservation obtained by the previous LDX<\/code> instruction is still valid, then the value in Rt\/zr<\/var> is stored to memory, and Rs<\/var> is set to 0. Otherwise, no store is performed, and Rs<\/var> is set to 1.<\/p>\n
Whether the store succeeds or fails, the STX<\/code> instructions clears the reservation.<\/p>\n
For these exclusive load and store instructions, the address must be a multiple of the number of bytes being loaded. If not, then the behavior is undefined: There is no requirement that an exception be raised.<\/p>\n
So don’t do that.<\/p>\n
It is also required that the STX<\/code> match the LDX<\/code> both in address and operand sizes. You cannot perform an LDX<\/code> for one address and follow up with a STX<\/code> to a different address. You also cannot perform a LDXR<\/code> and follow up with a STXRH<\/code> to the same address. You aren’t even allowed to do a LDXP<\/code> with two 32-bit registers and follow up with a STXR<\/code> with a single 64-bit register. Again, the behavior is undefined if you break this rule.<\/p>\n
The last instruction allows you to hit the reset button:<\/p>\n
    ; clear exclusive\r\n    clrex\r\n<\/pre>\n
The CLREX<\/code> discards any active reservation, and forces any subsequent STX<\/code> to fail. This typically happens as part of interrupt handling or context switching to ensure that undefined behavior doesn’t occur if the thread was interrupted while it was in the middle of a LDX<\/code>\/STX<\/code> sequence.<\/p>\n
These instructions are usually coupled with memory barriers, which we’ll look at soon, but the next entry will be a little diversion.<\/p>\n
Bonus chatter<\/b>: There is an optional instruction set extension (mandatory starting in version 8.4) which includes a large set of atomic read-modify-write operations.<\/p>\n
    ; atomic read-modify-write operation\r\n    ; Rt = previous value of [Xr]\r\n    ; [Xr] = Rt op Rs\r\n    ldadd   Rs\/zr, Rt\/zr, [Xr\/sp]       ; add\r\n    ldclr   Rs\/zr, Rt\/zr, [Xr\/sp]       ; and not\r\n    ldeor   Rs\/zr, Rt\/zr, [Xr\/sp]       ; exclusive or\r\n    ldset   Rs\/zr, Rt\/zr, [Xr\/sp]       ; or\r\n    ldsmax  Rs\/zr, Rt\/zr, [Xr\/sp]       ; signed maximum\r\n    ldsmin  Rs\/zr, Rt\/zr, [Xr\/sp]       ; signed minimum\r\n    ldumax  Rs\/zr, Rt\/zr, [Xr\/sp]       ; unsigned maximum\r\n    ldumin  Rs\/zr, Rt\/zr, [Xr\/sp]       ; unsigned minimum\r\n<\/pre>\n
By default, there is no memory ordering. You can add the suffix a<\/code> to load with acquire, the suffix l<\/code> to store with release, or the suffix al<\/code> to get both. Note, however, that the acquire suffix is ignored if the destination register Rt<\/var> is zr<\/var>.<\/p>\n
Furthermore, you can suffix b<\/code> for byte memory access or h<\/code> for halfword memory access.<\/p>\n
The overall syntax is therefore<\/p>\n\n\n\n\n
Prefix<\/th>\nOp<\/th>\nAcquire<\/th>\nRelease<\/th>\nSize<\/th>\n<\/tr>\n
ld<\/code><\/td>\nadd<\/code>
\nclr<\/code>
\neor<\/code>
\nset<\/code>
\nsmax<\/code>
\nsmin<\/code>
\numax<\/code>
\numin<\/code><\/td>\n		(none)
\na<\/code><\/td>\n		(none)
\nl<\/code><\/td>\n		(none)
\nb<\/code>
\nh<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For example, the instruction ldclrlh<\/code> means<\/p>\n