6

我有一些代码必须是线程安全的，其行为类似于：


protected long m_RunningValue
protected long m_RunningCounter
protected object m_Lock = new object();

public long RunningValue { get { return Interlocked.Read(m_RunningValue); } }
public long RunningCounter { get { return Interlocked.Read(m_RunningCounter); } }

public void DoCalculation(int newValue, int newQuantity)
{
   lock(m_Lock)
   {
       Interlocked.Add(ref m_RunningValueA, newValue);
       Interlocked.Add(ref m_RunningCounter, newQuantity);
       if(Interlocked.Read(ref newQuantity) == 0)
       { 
         ...m_RunningValue gets further modified here
       }
   }
}

计算必须同时锁定值和计数器，否则竞争条件可能会影响 if(...) 块，但是它们在被读出时根本不需要同步，即如果计数器和值在尝试阅读两者，这对我来说是 100% 好的。

读取时的互锁用于 64 位值的线程安全读取。

  1. 像这样混合联锁和锁安全吗？我在其他网页上读到混合它们是不安全的，但是如果这意味着混合它们是引入细微错误的好方法，或者如果在系统级别这会破坏所涉及的数据结构，我无法找到澄清。

  2. 所有这些互锁（64 位 .NET 4.0 运行时）的成本是否完全违背了在属性 get() 方法周围保存 ReaderWriterSlim 锁的目的？

4

1 回答 1

5

对于已编辑的版本，这不能保证是线程安全的。

考虑一个 32 位平台。这意味着必须在两个单独的操作中访问 64 位长值。

一个线程很可能读取数字的前半部分，然后从 CPU 中交换出来，而后半部分的值在其背后发生了变化。现在该线程具有完全无效的值。

Interlocked.Read的文档明确提到：

Read 方法和 Increment、Decrement 和 Add 方法的 64 位重载仅在 System.IntPtr 为 64 位长的系统上才是真正的原子。在其他系统上，这些方法相对于彼此是原子的，但相对于其他访问数据的方式而言不是原子的。因此，要在 32 位系统上实现线程安全，对64 位值的任何访问都必须通过 Interlocked 类的成员进行。

（强调我的）

编辑：现在它已被重新编辑，这看起来有点傻，但我将把它留在这里说明如果你在某些地方而不是其他地方联锁，那是没有意义的。

于 2010-12-07T23:45:15.733 回答