On a multicore x86, is a LOCK necessary as a prefix to XCHG?

Walter Bright picture Walter Bright · Jun 29, 2010 · Viewed 7.1k times · Source

If mem is a shared memory location, do I need:

XCHG EAX,mem

or:

LOCK XCHG EAX,mem

to do the exchange atomically?

Googling this yields both yes and no answers. Does anyone know this definitively?

Answer

CB Bailey picture CB Bailey · Jun 29, 2010

Intel's documentation seems pretty clear that it is redundant.

IA-32 Intel® Architecture Software Developer’s Manual Volume 3A: System Programming Guide, Part 1

7.1.2.1 says:

The operations on which the processor automatically follows the LOCK semantics are as follows:

  • When executing an XCHG instruction that references memory.

Similarly,

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 2B: Instruction Set Reference, N-Z

XCHG:

If a memory operand is referenced, the processor’s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL.

Note that this doesn't actually meant that the LOCK# signal is asserted whether or not the LOCK prefix is used, 7.1.4 describes how on later processors locking semantics are preserved without a LOCK# if the memory location is cached. Clever, and definitely over my head.