在多核 x86 上，是否需要 LOCK 作为 XCHG 的前缀？答案

【问题标题】：On a multicore x86, is a LOCK necessary as a prefix to XCHG?在多核 x86 上，是否需要 LOCK 作为 XCHG 的前缀？
【发布时间】：2011-03-09 19:55:16
【问题描述】：

如果mem是共享内存位置，我需要：

XCHG EAX,mem

或：

LOCK XCHG EAX,mem

以原子方式进行交换？

用谷歌搜索会得到是和否的答案。有谁确切知道这一点吗？

【问题讨论】：

【解决方案1】：

英特尔的文档似乎很清楚它是多余的。

IA-32 英特尔® 架构软件开发人员手册第 3A 卷：系统编程指南，第 1 部分

7.1.2.1 说：

处理器自动遵循 LOCK 语义的操作如下如下：

执行引用内存的 XCHG 指令时。

同样，

英特尔® 64 和 IA-32 架构软件开发人员手册第 2B 卷：指令集参考，N-Z

XCHG：

如果引用了内存操作数，处理器的锁定协议会自动在交换操作期间实施，无论是否存在 LOCK 前缀或 IOPL 的值。

请注意，这实际上并不意味着无论是否使用 LOCK 前缀都会断言 LOCK# 信号，7.1.4 描述了如果内存位置被缓存，如何在没有 LOCK# 的情况下在以后的处理器上保留锁定语义。聪明，绝对超出我的想象。

【讨论】：

Oracle Hotspot JVM 上的 PrintAssembly 选项似乎也同意这一点。生成程序集时，它确实没有在 x86-64 上的 xchg 指令上具有锁定前缀。
该部分是手册当前版本中的8.1.2.1 Automatic Locking，而不是7.1.2.1。

【解决方案2】：

自 386 天以来，无论您是否在其上添加锁定前缀，xchg 都会断言 Lock 信号。 Intel's documentation 在 IA-32 指令集参考 N-Z 中非常清楚地涵盖了这一点。

【讨论】：

【解决方案3】：

根据80386 Instruction Manual，BUS LOCK 在交换期间被断言。 LOCK 前缀对此操作没有优先级，I/O Privilege Level 的值也没有。

我的建议是，由于文档声明BUS LOCK 被断言而不管LOCK 前缀的存在，LOCK XCHG EAX, mem 在其他方面是安全的。如有疑问，请添加LOCK。

【讨论】：