为什么需要锁来实现只读的 int 属性？

Question

我是线程新手，在blog 中遇到了一个自定义线程池实现示例。我只是粘贴代码的必要部分：

Public Class ThreadPool

    Private CountLock As New Object
    Private _Count As Integer

    Public ReadOnly Property ThreadCount() As Integer
      Get
         SyncLock CountLock
           Return _Count
         End SyncLock
      End Get
    End Property

    Public Sub Open()
      Interlocked.Increment(_Count)
    End Sub

    Public Sub Close()
      Interlocked.Decrement(_Count)
      ....
    End Sub

EndClass

我的问题是，为什么我们需要一个锁来实现只读的 ThreadCount 属性？

Answer 1

这段代码应该使用Interlocked.CompareExchange 来访问属性getter 中的值。将 param3 (comparand) 设置为你知道在变量中看不到的东西，比如Int32.MinValue，然后函数只返回_count 的当前值。

如果Interlocked 操作用于对变量的所有访问，则锁是多余的，因为通过Interlocked 类方法的所有访问都是原子的。

Answer 2

我不知道为什么作者选择在类的一个部分使用锁，而在其他部分使用无锁技术。但是，我可以假设作者这样做是为了在读取Interger 时创建一个显式内存屏障。 VB 不包含等效于 C# 的 volatile 关键字，因此只剩下 4 种其他常用方法来确保读取安全。我已经按照我为这个特定场景选择的顺序列出了这些。

• Interlocked.CompareExchange
• Thread.VolatileRead
• Thread.MemoryBarrier
• 同步锁定

需要内存屏障来防止 VB 或 JIT 编译器移动指令。在没有内存屏障的情况下，最可能的优化是将读取提升到循环之外。考虑一下ThreadCount 属性的这种实际用法。

Sub LoggingThread()
  Do While True
    Trace.WriteLine(ThreadPool.ThreadCount)
  Loop
End Sub

在此示例中，CLR 可能会内联 ThreadCount，然后可能会“提升”对 _Count 的读取，并在循环开始之前将其缓存在 CPU 寄存器中。效果是始终显示相同的值。¹

¹_{实际上，Trace.WriteLine 调用本身会生成一个内存屏障，这会导致代码意外安全。该示例旨在简单说明可能发生的情况。}

Answer 3

锁将强制设置内存屏障，因此如果最后写入的值是由不同的 CPU 写入的，则不会读取 CPU 缓存中的陈旧值。没有锁定的Thread.VolatileRead() 也可以这样做。

Answer 4

这没有任何意义，因为您修改属性的位置没有锁。也许代码之前没有使用互锁操作，甚至在打开/关闭时也使用了 SyncLock？在这种情况下，读访问也确实需要 SyncLock。