为何C#的Thread.MemoryBarrier()使用lock or而非mfence指令？

从微软旧文档《C#内存模型的理论与实践（第二部分）》以及汇编输出可以看到，.NET的Thread.MemoryBarrier()被JIT编译为lock or dword ptr [rsp], 0指令，而非Intel提供的、看似更适合的mfence。这个选择主要源于兼容性、历史遗留以及性能层面的考量，具体分析如下：

• 老处理器兼容性：mfence是SSE2指令集的产物，2001年的Pentium 4才开始支持。而lock前缀是x86架构从早期就具备的指令，CLR最初设计时需要兼容大量更早的处理器（比如Pentium III及之前型号），使用lock前缀的方案能覆盖更广泛的硬件环境，避免因指令集不支持导致的运行错误。

• 性能与缓存行为：虽然部分场景下mfence可能提供更强的保证，但在x86/amd64的强内存模型下，二者的实际内存屏障效果差异极小。而lock or dword ptr [rsp], 0有一个关键优势：它操作的是栈内存，栈内存几乎总是处于L1缓存中，执行开销极低。部分老处理器上mfence的延迟反而更高。另外，lock前缀会触发CPU的缓存一致性协议（MESI），强制刷新存储缓冲区并同步所有核心的内存视图，完全满足CLR对全内存屏障的要求。

• 历史实现的延续性：早期.NET Framework的JIT就采用了lock前缀的方案实现内存屏障，后续版本为了保持兼容性和稳定性，延续了这一实现。虽然mfence后来逐渐普及，但替换现有实现没有带来足够的收益，反而可能引入潜在的兼容性风险。

• 跨架构实现的一致性逻辑：在ARM64架构下，CLR使用dmb指令实现全内存屏障——这本质上是针对不同架构的特性选择最优的屏障指令。x86上的lock前缀方案和ARM64的dmb一样，都是符合架构内存模型的可靠实现，而非刻意选择“不直观”的指令。

补充：旧版.NET Framework的Interlocked.SpeculationBarrier等方法会生成mfence，是因为这些方法的设计目标和MemoryBarrier()不同，它们更偏向于特定指令集下的优化，而MemoryBarrier()需要兼顾最广泛的兼容性。

内容的提问来源于stack exchange，提问作者Rook