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
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
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.
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.
XCHG
instruction is always locked if it references memory, even if there is no LOCK prefix specified for it. So the memory ordering rule referred to above should indeed apply and no additional barrier is needed. –
Felucca No. xchg
is guaranteed to compile into something, that will assure consistency on the hardware level.
lock
prefix is implicit for xchg
and therefore not explicitely needed for x86. –
Hydroplane xchg instruction has an implicit lock prefix according to Intel manuals.
© 2022 - 2024 — McMap. All rights reserved.
"+m"
memory operand, because it's read and written. The"memory"
clobber probably makes it safe to write an input operand, though. – Appease