x86：这里需要内存屏障吗？

Question

在 WB 内存中，a = b = 0

P1:
a = 1
SFENCE
b = 1

P2:
WHILE (b == 0) {}
LFENCE
ASSERT (a == 0)

据我了解，这里不需要SFENCE 或LFENCE。

也就是说，因为对于这种内存类型，x86 确保：

1. 不能用旧的读取重新排序读取
2. 商店不能与旧商店重新订购
3. 商店是可传递可见的

Answer 1

lfence 和 sfence asm 指令是无操作的，除非您使用 NT 存储（或 NT 从 WC 内存加载，例如视频 RAM）。 （实际上是movntdqa loads might only be ordered by mfence on paper，而不是lfence。在这种情况下，我不知道你什么时候会使用lfence。它与sfence+mfence同时添加到ISA NT 商店，在movntdqa 之前，可能只是为了完整性/以防万一。）

在这一点上有时会引起混淆，因为lfence 和sfence 的C/C++ 内在函数也是编译器障碍。在 C/C++ 中需要 ，但可以使用 GNU C asm("":::"memory"); 或（订购轻松-atomic 操作¹）std::atomic_signal_fence(std::memory_order_acq_rel) 更便宜地获得。限制 compile-time reordering 而不使编译器发出任何无用的 asm 屏障指令。

---

运行时重新排序已被 x86 内存模型阻止，但 StoreLoad reordering 除外，它需要 mfence 才能阻止。 lfence + sfence 不要加起来 mfence。有关这些说明，请参阅 Does it make any sense instruction LFENCE in processors x86/x86_64? 和其他各种 SO Q&A。

这就是为什么std::atomic_thread_fence(std::memory_order_acq_rel) also compiles to zero instructions on x86 的原因，但是对于弱有序架构的障碍。

---

lfence 也是 Intel 微架构上的序列化指令（但可能不是 AMD？）。一直以来，但英特尔最近将此保证正式化，因此 Spectre 缓解技术可以安全地使用它，而不是更不方便的cpuid。

---

• 脚注 1：

gcc 上的atomic_signal_fence 也可能是普通非atomic 变量的编译器障碍；这是我最后一次使用 gcc 检查（而 atomic_thread_fence 不是），但这可能只是一个实现细节，因为没有涉及任何 atomic 变量。当有atomic 变量时，编译器知道这些变量可能会提供排序，让其他线程在没有UB 的情况下访问非原子变量，因此需要排序。