c# - 内存屏障与互锁对内存缓存一致性时序的影响

Question

简化问题:

与内存屏障相比，互锁操作导致的内存缓存一致性(或“刷新”)时间是否存在差异？让我们在 C# 中考虑 - 任何互锁操作与 Thread.MemoryBarrier()。我相信是有区别的。

背景:

我阅读了很少关于内存屏障的信息 - 所有关于防止特定类型的内存交互指令重新排序的影响，但我找不到关于它们是否应该导致读取的立即刷新的一致信息/写队列。

我实际上发现很少有消息来源提到不保证操作的即时性(只保证防止特定的重新排序)。例如

Wikipedia :“但是，需要明确的是，这并不意味着任何操作都将在屏障完成时完成；仅保证操作完成的顺序(当它们完成时)”

Freebsd.org (障碍是特定于硬件的，所以我想特定的操作系统并不重要):“内存障碍只是确定内存操作的相对顺序；它们不对内存操作的时间做出任何保证”

另一方面，互锁操作 - 根据他们的定义 - 导致立即刷新所有内存缓冲区以保证更新变量的最新值导致内存子系统锁定整个缓存行的值，以防止从任何其他 CPU/核心访问(包括读取)，直到操作完成。

我是对还是错？

免责声明:

这是我在这里的原始问题的演变 Variable freshness guarantee in .NET (volatile vs. volatile read)

编辑 1:修复了我关于联锁操作的陈述 - 内联文本。

编辑 2:完全删除演示代码+它的讨论(因为有些人提示信息太多)

Answer 1

要了解 C# 联锁操作，您需要了解 Win32 联锁操作。

“纯”互锁操作本身只会影响操作直接引用的数据的新鲜度。

但在 Win32 中，互锁操作过去常常表示完整的内存屏障。我相信这主要是为了避免在新硬件上破坏旧程序。所以 InterlockedAdd 做了两件事:互锁加法(非常便宜，不影响缓存)和全内存屏障(相当繁重的操作)。

后来，Microsoft 意识到这很昂贵，并添加了每个操作的版本，这些版本没有内存屏障或部分内存屏障。

所以现在(在 Win32 世界中)几乎所有东西都有四个版本:例如InterlockedAdd(全栅栏)、InterlockedAddAcquire(读栅栏)、InterlockedAddRelease(写栅栏)、纯InterlockedAddNoFence(无栅栏)。

在 C# 世界中，只有一个版本，它与“经典的”InterlockedAdd 相匹配——它也实现了完整的内存栅栏。