CMPXCHG

With a LOCK prefix and a memory destination, CMPXCHG is the compare-and-swap of x86. GCC 14 and Clang 23 at -O2 compile C’s atomic_compare_exchange_strong to it, and atomic read-modify-writes that have no instruction of their own, such as a fetch-and-OR whose old value is used, to this loop:

1. Load the shared value into the accumulator (EAX or RAX).
2. Compute the new value from it in another register.
3. Execute LOCK CMPXCHG with the shared location as the destination and the new value as the source. If the location still holds what step 1 loaded, the new value is stored and ZF is set.
4. If ZF is clear, another thread changed the value in between. The accumulator now holds that value, so the loop goes back to step 2 without loading it again.

Taking a spinlock is the shortest case: 0 in EAX, 1 in the source register, and the lock is taken when ZF is set.

Points that are easy to miss:

• Only the LOCK form is atomic with respect to other processors, and LOCK needs a memory destination (#UD otherwise).
• The destination is written even when the comparison fails: Intel’s and AMD’s manuals both say the processor writes back the value it read. CMPXCHG therefore needs write access to the page either way.
• With 32-bit operands the outcome decides which register is written. On success EAX is not written, so bits 63:32 of RAX keep their old value; on failure EAX is loaded and bits 63:32 are cleared. A register destination is the other way round: written and zero-extended on success, left whole on failure. Zen 5 and the Intel processor that ran the cases of the Operation section agree.
• A locked operand that crosses a cache-line boundary makes the processor lock the bus, which system software can turn into #AC with split-lock disable (Intel’s Volume 3A, Section 11.1.2.3). Intel’s manual recommends naturally aligned locked operands, and AMD’s optimization guide for Zen 5 ones that do not cross a 64-byte boundary.

For two registers’ worth of data, such as a pointer with a version counter against the ABA problem, use CMPXCHG8B or CMPXCHG16B. XADD and XCHG do fetch-and-add and swap in one step, without a loop, and CMPccXADD adds only when a condition holds.

In the optimization guide

What the optimization guide says about CMPXCHG, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Memory

• Sharing between cores: A contended lock is best taken by spinning on a plain load with PAUSE and trying cmpxchg only when it looks free, with backoff.

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

old = dest.read()                # with LOCK: one atomic read-modify-write
flags = sub_flags(rAX, old)      # as CMP rAX, old
if rAX == old:
    dest.write(src)              # a 32-bit register: bits 63:32 cleared
else:
    rAX = old                    # EAX: bits 63:32 cleared
    if dest.is_memory:
        dest.write(old)          # memory is written back all the same
    # a register destination is not written: bits 63:32 of a 32-bit
    # one stay as they were

Operands

Flags

Attributes

What else XED records about the forms. How to read.

Memory forms without LOCK

accepts a LOCK prefix

LOCK forms

locked: atomic read-modify-write; accepts XACQUIRE; accepts XRELEASE

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More General-purpose instructions

• ADD
• AND
• BOUND
• BSF
• BSR
• BSWAP
• BT
• BTC
• BTR
• BTS
• CALL
• CBW
• CDQ
• CDQE
• CLC
• CLD
• CLI
• CMC
• CMP
• CMPS
• CMPXCHG8B
• CPUID
• CQO
• CWD
• CWDE
• DAA
• DAS
• DEC
• DIV
• ENTER
• IDIV
• IMUL
• IN
• INC
• INS
• INT
• INT1
• INT3
• INTO
• IRET

All 109 General-purpose instructions