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

Question

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 1

As per the 80386 Instruction Manual, BUS LOCK is asserted for the duration of the exchange. The LOCK prefix has no precedence for this operation and neither does the value of the I/O Privilege Level.

My suggestion is that since the documentation states that BUS LOCK is asserted regardless of the presence of the LOCK prefix, LOCK XCHG EAX, mem is otherwise safe. When in doubt, add a LOCK.

Answer 2

Since 386 days, xchg will assert the Lock signal whether or not you put the lock prefix on it. Intel's documentation covers this quite clearly in IA-32 instruction set reference N-Z.

Answer 3

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.