在多核 x86 上，是否需要将 LOCK 作为 XCHG 的前缀？
如果mem是共享内存位置，我是否需要：
XCHG EAX,mem
或：
LOCK XCHG EAX,mem
以原子方式进行交换？
谷歌搜索会得到“是”和“否”的答案。有谁明确知道这一点吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
英特尔的文档似乎很清楚它是多余的。
IA-32 英特尔® 架构
软件开发人员手册
第 3A 卷：
系统编程指南，第 1 部分
7.1.2.1 说：
同样，
英特尔® 64 和 IA-32 架构
软件开发人员手册
第 2B 卷：
指令集参考，NZ
XCHG：
请注意，这实际上并不意味着无论是否使用 LOCK 前缀，都会断言 LOCK# 信号，7.1.4 描述了如果内存位置被缓存，则在后续处理器上如何在没有 LOCK# 的情况下保留锁定语义。聪明，绝对超出了我的想象。
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:
Similarly,
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 2B:
Instruction Set Reference, N-Z
XCHG:
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.
自 386 天以来，无论您是否在其上添加锁定前缀，xchg 都会断言锁定信号。 Intel 文档 在 IA-32 指令集参考 NZ 中非常清楚地介绍了这一点。
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.
根据 80386 说明手册，
BUS LOCK在交换期间被置位。对于此操作，LOCK前缀没有优先级，I/O 权限级别。我的建议是，由于文档指出无论是否存在 LOCK 前缀，都会断言 BUS LOCK ，否则 LOCK XCHG EAX, mem 会被断言安全的。如有疑问，请添加
LOCK。As per the 80386 Instruction Manual,
BUS LOCKis asserted for the duration of the exchange. TheLOCKprefix 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 LOCKis asserted regardless of the presence of theLOCKprefix,LOCK XCHG EAX, memis otherwise safe. When in doubt, add aLOCK.