I have a set and test xchg
based assembly lock. my question is :
Do we need to use memory fencing (mfence
, sfence
or lf
xchg instruction has an implicit lock prefix according to Intel manuals.
According to Chapter 8 Bus Locking, of the Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A
The memory-ordering model prevents loads and stores from being reordered with locked instructions that execute earlier or later.
So the locked XCHG
instruction acts as a memory barrier, and no additional barrier is needed.
As said in the other answers the lock prefix is implicit, here, so there is no problem on the assembler level. The problem may lay on the C (or C++) level when you use that as inline assembler. Here you have to ensure that the compiler doesn't reorder instructions with respect to your xchg
. If you are using gcc (or cousins) you would typically do something like:
__asm__ __volatile__("xchgl %1, %0"
: "=r"(ret)
: "m"(*point), "0"(ret)
: "memory");
that is declare the instruction as volatile and add the "memory" clobber.
No. xchg
is guaranteed to compile into something, that will assure consistency on the hardware level.