读取由 Interlocked 在其他线程上更新的 int

Question

（这是重复的：How to correctly read an Interlocked.Increment'ed int field? 但是，在阅读了答案和 cmets 之后，我仍然不确定正确的答案。）

有些代码我不拥有并且无法更改为使用在几个不同线程中递增 int 计数器 (numberOfUpdates) 的锁。所有调用使用：

Interlocked.Increment(ref numberOfUpdates);

我想在我的代码中读取 numberOfUpdates。现在，由于这是一个 int，我知道它不能撕裂。但是，确保我获得最新价值的最佳方式是什么？看来我的选择是：

int localNumberOfUpdates = Interlocked.CompareExchange(ref numberOfUpdates, 0, 0);

或者

int localNumberOfUpdates = Thread.VolatileRead(numberOfUpdates);

两者都可以工作吗（无论优化、重新排序、缓存等如何，都可以提供最新的价值）？一个比另一个更受欢迎吗？还有第三种更好的选择吗？

Answer 1

我坚信，如果您使用 interlocked 来增加共享数据，那么您应该在访问该共享数据的任何地方使用 interlocked。同样，如果您使用在此处插入您最喜欢的同步原语来增加共享数据，那么您应该在您访问该共享数据的任何地方使用在此处插入您最喜欢的同步原语。

int localNumberOfUpdates = Interlocked.CompareExchange(ref numberOfUpdates, 0, 0);

将为您提供您所寻找的。正如其他人所说，联锁操作是原子的。因此 Interlocked.CompareExchange 将始终返回最新的值。我一直使用它来访问简单的共享数据，例如计数器。

我对 Thread.VolatileRead 不太熟悉，但我怀疑它也会返回最新的值。如果只是为了保持一致，我会坚持使用联锁的方法。

---

附加信息：

我建议您查看 Jon Skeet 的回答，了解您可能想要回避 Thread.VolatileRead() 的原因：Thread.VolatileRead Implementation

Eric Lippert 在他的博客http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-immutability-are-different-part-three.aspx 中讨论了波动性和 C# 内存模型所做的保证。直截了当：“我不会尝试编写任何低锁代码，除了互锁操作的最琐碎用法。我将“易失性”的用法留给真正的专家。”

我同意 Hans 的观点，即该值将始终过时至少几个 ns，但如果您有一个不可接受的用例，它可能不太适合像 C# 这样的垃圾收集语言或非- 实时操作系统。 Joe Duffy 在这里有一篇关于联锁方法时效性的好文章：http://joeduffyblog.com/2008/06/13/volatile-reads-and-writes-and-timeliness/

Answer 2

嗯，正如 Hans Passant 所说，您阅读的任何值都会有些陈旧。您只能控制保证 other 共享值与您刚刚读取的共享值一致，在代码中间使用内存栅栏读取多个没有锁的共享值（即：处于相同程度的“陈旧”）

栅栏还具有破坏某些编译器优化和重新排序的效果，从而防止在不同平台上的发布模式下出现意外行为。

Thread.VolatileRead 将导致发出一个完整的内存栅栏，这样就不会围绕您对 int 的读取（在读取它的方法中）重新排序读取或写入。显然，如果您只读取一个共享值（并且您没有读取其他共享值并且它们的顺序和一致性都很重要），那么它似乎没有必要......

但我认为无论如何你都需要它来击败编译器或 CPU 的一些优化，这样你就不会得到比必要的更“陈旧”的读取。

一个虚拟的 Interlocked.CompareExchange 将做与 Thread.VolatileRead 相同的事情（完全围栏和优化失败行为）。

CancellationTokenSource 使用的框架中遵循了一个模式 http://referencesource.microsoft.com/#mscorlib/system/threading/CancellationTokenSource.cs#64

//m_state uses the pattern "volatile int32 reads, with cmpxch writes" which is safe for updates and cannot suffer torn reads. 
private volatile int m_state;

public bool IsCancellationRequested
{
    get { return m_state >= NOTIFYING; } 
}

// ....
if (Interlocked.CompareExchange(ref m_state, NOTIFYING, NOT_CANCELED) == NOT_CANCELED) {
}
// ....

volatile 关键字具有发射“半”栅栏的效果。 （即：它阻止读取/写入在读取之前移动，并阻止读取/写入在写入之后移动）。

Answer 3

两者都可以工作吗（在提供最新价值的意义上，无论优化、重新排序、缓存等如何）？

不，您获得的值总是过时。该值的陈旧程度是完全不可预测的。在绝大多数情况下，它会过时几纳秒，取决于你对价值采取行动的速度。但是没有合理的上限：

• 当您的线程将另一个线程上下文切换到内核时，它可能会丢失处理器。典型的延迟约为 45 毫秒，没有确定的上限。这不意味着您的进程中的另一个线程也被关闭，它可以继续驱动并继续改变值。
• 就像任何用户模式代码一样，您的代码也会受到页面错误的影响。当处理器需要 RAM 用于另一个进程时发生。在可以并且将分页活动代码的重负载机器上。例如，鼠标驱动程序代码有时会出现冻结的鼠标光标。
• 托管线程受到近乎随机的垃圾回收暂停。往往是较小的问题，因为很可能另一个正在改变值的线程也将被暂停。

无论您如何处理该值，都需要考虑到这一点。也许不用说，这非常非常困难。实际例子很难找到。 .NET Framework 是一大块久经沙场的代码。您可以从the Reference Source 看到对 VolatileRead 用法的交叉引用。命中数：0。

Answer 4

Thread.VolatileRead(numberOfUpdates) 是你想要的。 numberOfUpdates 是 Int32，因此默认情况下您已经具有原子性，Thread.VolatileRead 将确保处理波动性。

如果 numberOfUpdates 被定义为 volatile int numberOfUpdates; 你不必这样做 这个，因为它的所有读取都已经是易失性读取。

---

对于Interlocked.CompareExchange 是否更合适似乎存在混淆。请考虑以下两个文档摘录。

来自Thread.VolatileRead 文档：

读取字段的值。该值是计算机中任何处理器最新写入的值，与处理器数量或处理器缓存状态无关。

来自Interlocked.CompareExchange 文档：

比较两个 32 位有符号整数是否相等，如果相等，则替换其中一个值。

就这些方法的规定行为而言，Thread.VolatileRead 显然更合适。您不想将numberOfUpdates 与另一个值进行比较，也不想替换它的值。你想读取它的值。

---

Lasse 在他的评论中提出了一个很好的观点：使用简单的锁定可能会更好。当其他代码想要更新 numberOfUpdates 时，它会执行以下操作。

lock (state)
{
    state.numberOfUpdates++;
}

当你想阅读它时，你可以执行以下操作。

int value;
lock (state)
{
    value = state.numberOfUpdates;
}

这将确保您对原子性和易变性的要求，而无需深入研究更晦涩、相对低级的多线程原语。