Do we need mfence when using xchg

I have a set and test `xchg` based assembly lock. my question is :

Do we need to use memory fencing (`mfence`, `sfence` or `lfence` ) when using `xchg` instruction ?

Edit :

64 Bit platform : with Intel nehalem

No. `xchg` is guaranteed to compile into something, that will assure consistency on the hardware level.

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.

xchg instruction has an implicit lock prefix according to Intel manuals.