线程安全类是否应该在其构造函数的末尾有一个内存屏障？

Question

当实现一个线程安全的类时，我是否应该在其构造函数的末尾包含一个内存屏障，以确保任何内部结构在可以访问之前都已完成初始化？还是消费者有责任在将实例提供给其他线程之前插入内存屏障？

简化问题：

下面的代码中是否存在竞争风险，由于在初始化和线程安全类的访问之间缺乏内存屏障，可能会导致错误行为？或者线程安全类本身应该防止这种情况发生吗？

ConcurrentQueue<int> queue = null;

Parallel.Invoke(
    () => queue = new ConcurrentQueue<int>(),
    () => queue?.Enqueue(5));

请注意，程序不排队是可以接受的，如果第二个委托在第一个委托之前执行就会发生这种情况。 （这里的空条件运算符?. 可以防止NullReferenceException。）但是，程序抛出IndexOutOfRangeException、NullReferenceException、入队5 多次是不可接受的，会卡在一个无限循环，或者做任何其他由内部结构上的竞争风险引起的奇怪事情。

详细问题：

具体来说，假设我正在为队列实现一个简单的线程安全包装器。 （我知道.NET 已经提供了ConcurrentQueue<T>；这只是一个例子。）我可以写：

public class ThreadSafeQueue<T>
{
    private readonly Queue<T> _queue;

    public ThreadSafeQueue()
    {
        _queue = new Queue<T>();

        // Thread.MemoryBarrier(); // Is this line required?
    }

    public void Enqueue(T item)
    {
        lock (_queue)
        {
            _queue.Enqueue(item);
        }
    }

    public bool TryDequeue(out T item)
    {
        lock (_queue)
        {
            if (_queue.Count == 0)
            {
                item = default(T);
                return false;
            }

            item = _queue.Dequeue();
            return true;
        }
    }
}

这个实现是线程安全的，一旦初始化。但是，如果初始化本身由另一个消费者线程竞争，则可能会出现竞争危险，即后一个线程将在内部 Queue<T> 初始化之前访问实例。作为一个人为的例子：

ThreadSafeQueue<int> queue = null;

Parallel.For(0, 10000, i =>
{
    if (i == 0)
        queue = new ThreadSafeQueue<int>();
    else if (i % 2 == 0)
        queue?.Enqueue(i);
    else
    {
        int item = -1;
        if (queue?.TryDequeue(out item) == true)
            Console.WriteLine(item);
    }
});

上面的代码遗漏一些数字是可以接受的；然而，如果没有内存屏障，它也可能会得到一个NullReferenceException（或其他一些奇怪的结果），因为在调用Enqueue 或TryDequeue 时内部Queue<T> 尚未初始化。

是线程安全类的责任在其构造函数的末尾包含一个内存屏障，还是消费者应该在类的实例化和它对其他线程的可见性之间包含一个内存屏障？ .NET Framework 中标记为线程安全的类的约定是什么？

编辑：这是一个高级线程主题，所以我理解一些 cmets 的困惑。如果在没有正确同步的情况下从其他线程访问，实例可能显示为半生不熟。该主题在双重检查锁定的上下文中进行了广泛讨论，在 ECMA CLI 规范下不使用内存屏障（例如通过volatile）打破了双重检查锁定。每Jon Skeet:

Java 内存模型不能确保构造函数在对新对象的引用分配给实例之前完成。 Java 内存模型在 1.5 版中进行了重新设计，但在没有 volatile 变量（如在 C# 中）的情况下，双重检查锁定仍然被破坏。

没有任何内存障碍，它在 ECMA CLI 规范中也被打破了。在 .NET 2.0 内存模型（比 ECMA 规范更强）下它可能是安全的，但我宁愿不依赖那些更强大的语义，特别是如果对安全性有任何疑问。

Answer 1

Lazy<T> 是线程安全初始化的一个非常好的选择。我认为应该让消费者来提供：

var queue = new Lazy<ThreadSafeQueue<int>>(() => new ThreadSafeQueue<int>());

Parallel.For(0, 10000, i =>
{

    else if (i % 2 == 0)
        queue.Value.Enqueue(i);
    else
    {
        int item = -1;
        if (queue.Value.TryDequeue(out item) == true)
            Console.WriteLine(item);
    }
});

Answer 2

线程安全类是否应该在其末尾有一个内存屏障 构造函数？

我看不出这是什么原因。 queue 是从一个线程分配并从另一个线程访问的局部变量。这种并发访问应该是同步的，这是访问代码的责任。它与变量的构造函数或类型无关，这种访问应该始终显式同步，否则即使对于原始类型，您也会进入危险区域（即使分配是原子的，您也可能会被一些缓存陷阱捕获）。如果对变量的访问正确同步，则不需要构造函数的任何支持。

Answer 3

我将尝试根据 Servy 和 Douglas 的 cmets 以及来自其他相关问题的信息来回答这个有趣且精心提出的问题。以下只是我的假设，并非来自可靠来源的可靠信息。

1. 线程安全的类具有可以被多个线程同时安全调用的属性和方法，但它们的构造函数不是线程安全的。这意味着线程完全有可能“看到”具有无效状态的线程安全类的实例，前提是该实例是由另一个线程同时构造的。

2. 在构造函数末尾添加Thread.MemoryBarrier(); 行不足以使构造函数线程安全，因为该语句仅影响运行构造函数的线程¹。其他可能同时访问在建实例的线程不受影响。内存可见性是协作的，一个线程无法通过以非协作方式更改另一个线程的执行流程（或使另一个线程正在运行的 CPU 内核的本地缓存无效）来改变另一个线程“看到”的内容。

3. 确保所有线程都看到具有有效状态的实例的正确且可靠的方法是在所有线程中包含适当的内存屏障。这可以通过将实例声明为volatile（如果它是类的字段）或使用静态Volatile 类的方法来实现：

ThreadSafeQueue<int> queue = null;

Parallel.For(0, 10000, i =>
{
    if (i == 0)
        Volatile.Write(ref queue, new ThreadSafeQueue<int>());
    else if (i % 2 == 0)
        Volatile.Read(ref queue)?.Enqueue(i);
    else
    {
        int item = -1;
        if (Volatile.Read(ref queue)?.TryDequeue(out item) == true)
            Console.WriteLine(item);
    }
});

在这个特定的示例中，在调用Parallel.For 方法之前实例化queue 变量会更简单、更有效。这样做会使显式的Volatile 调用变得不必要。 Parallel.For 方法在内部使用Tasks，TPL 在每个任务的开始/结束处包含适当的内存屏障。内存屏障由 .NET 基础结构、任何启动线程或导致委托在另一个线程上执行的内置机制隐式自动生成。 (citation)

我再说一遍，我对上述信息的正确性不是 100% 有信心。

¹ _{引用Thread.MemoryBarrier 方法的documentation：同步内存访问如下：执行当前线程的处理器不能以这样一种方式重新排序指令，即在调用之前内存访问MemoryBarrier() 在调用 MemoryBarrier() 之后的内存访问之后执行。}

Answer 4

不，构造函数中不需要内存屏障。你的假设，即使展示了一些创造性的想法 - 是错误的。没有线程可以获得queue 的半支持实例。只有在初始化完成后，新的引用才对其他线程“可见”。假设 thread_1 是第一个初始化 queue 的线程 - 它通过 ctor 代码，但 queue 在主堆栈中的引用仍然为空！仅当 thread_1 存在时，它才分配引用的构造函数代码。

请参阅下面的 cmets 和 OP 详细说明的问题。