On a multicore x86, is a LOCK necessary as a prefix to XCHG?
atomic, multithreading, x86
Solution
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.
Problem
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?