此双重检查锁定修复有什么问题？

Question

所以我现在看到很多文章声称在 C++ 上双重检查锁定（通常用于防止多个线程尝试初始化延迟创建的单例）已被破坏。 正常的双重检查锁定代码如下所示：

class singleton {
private:
    singleton(); // private constructor so users must call instance()
    static boost::mutex _init_mutex;

public:
    static singleton & instance()
    {
        static singleton* instance;

        if(!instance)
        {
            boost::mutex::scoped_lock lock(_init_mutex);

            if(!instance)           
                instance = new singleton;
        }

        return *instance;
    }
};

问题显然是分配实例的行 - 编译器可以自由分配对象，然后将指针分配给它，或者将指针设置到将分配的位置，然后分配它。 后一种情况打破了习惯用法——一个线程可以分配内存并分配指针，但在进入睡眠状态之前不运行单例的构造函数——然后第二个线程将看到实例不为空并尝试返回它，尽管它还没有建成。

我看到一个建议使用线程本地布尔值并且检查它而不是实例。 像这样的事情：

class singleton {
private:
    singleton(); // private constructor so users must call instance()
    static boost::mutex _init_mutex;
    static boost::thread_specific_ptr<int> _sync_check;

public:
    static singleton & instance()
    {
        static singleton* instance;

        if(!_sync_check.get())
        {
            boost::mutex::scoped_lock lock(_init_mutex);

            if(!instance)           
                instance = new singleton;

            // Any non-null value would work, we're really just using it as a
            // thread specific bool.
            _sync_check = reinterpret_cast<int*>(1);
        }

        return *instance;
    }
};

这样每个线程最终都会检查实例是否已创建一次，但在那之后停止，这会带来一些性能损失，但仍然没有锁定每个调用那么糟糕。 但是如果我们只使用本地静态布尔值怎么办？：

class singleton {
private:
    singleton(); // private constructor so users must call instance()
    static boost::mutex _init_mutex;

public:
    static singleton & instance()
    {
        static bool sync_check = false;
        static singleton* instance;

        if(!sync_check)
        {
            boost::mutex::scoped_lock lock(_init_mutex);

            if(!instance)           
                instance = new singleton;

            sync_check = true;
        }

        return *instance;
    }
};

为什么这不起作用？ 即使sync_check 在被分配到另一个线程中时由一个线程读取，垃圾值仍将是非零，因此为真。 多布博士的这篇文章声称你必须锁定，因为你永远不会赢得与编译器对指令进行重新排序。 这让我觉得这一定是因为某种原因不起作用，但我不明白为什么。 如果对序列点的要求像 Dobb 博士的文章让我相信的那样丢失，我不明白为什么锁之后的任何代码都无法重新排序到锁之前。 这会让C++多线程断了时期。

我想我可以看到编译器被允许专门将sync_check重新排序到锁之前，因为它是一个局部变量（即使它是静态的，我们也不会返回指向它的引用或指针）——但这仍然可以解决通过使其成为静态成员（实际上是全局的）来代替。

那么这行得通还是行不通呢？ 为什么？

Answer 1

您的修复不会修复任何问题，因为对sync_check 和实例的写入可能会在CPU 上无序完成。 举个例子，假设对实例的前两次调用大约同时发生在两个不同的 CPU 上。 第一个线程将按顺序获取锁、初始化指针并将sync_check 设置为true，但处理器可能会更改写入内存的顺序。 在另一个CPU上，第二个线程可以检查sync_check，看看它是否为真，但实例可能尚未写入内存。 请参阅Xbox 360 和 Microsoft Windows 的无锁编程注意事项 了解详情。

您提到的线程特定的sync_check 解决方案应该可以工作（假设您将指针初始化为0）。

Answer 2

这里有一些关于此内容的精彩读物（尽管它是面向 .net/c# 的）：http ://msdn.microsoft.com/en-us/magazine/cc163715.aspx

归根结底，您需要能够告诉 CPU 它无法重新排序此变量访问的读/写（从最初的奔腾开始，如果 CPU 认为逻辑不受影响，它可以重新排序某些指令），并且它需要确保缓存的一致性（不要忘记这一点 - 我们开发人员可以假装所有内存只是一个平面资源，但实际上，每个 CPU 核心都有缓存，一些未共享（L1），一些有时可能共享（L2））——您的初始化可能会写入主 RAM，但另一个核心可能具有未初始化的缓存缓存中的值。 如果没有任何并发​​语义，CPU 可能不知道它的缓存是脏的。

我不知道 C++ 方面，但在 .net 中，您可以将变量指定为 易失性的，以保护对其的访问（或者您可以使用 System.Threading 中的内存读/写屏障方法）。

顺便说一句，我读到，在 .net 2.0 中，双重检查锁定保证在没有“易失性”变量的情况下工作（对于任何 .net 读者来说）——这对您的 C++ 代码没有帮助。

如果你想安全，你需要在 C++ 中执行相当于在 C# 中将变量标记为 易失性的操作。

Answer 3

“后一种情况打破了习惯用法——两个线程最终可能会创建单例。”

但是如果我正确理解代码，第一个示例，您检查实例是否已经存在（可能由多个线程同时执行），如果没有一个线程锁定它并创建实例 - 只有一个此时线程可以执行创建。 所有其他线程都被锁定并等待。

一旦创建了实例并且互斥锁被解锁，下一个等待线程将锁定互斥锁，但它不会尝试创建新实例，因为检查将失败。

下次检查实例变量时，它将被设置，因此没有线程会尝试创建新实例。

我不确定一个线程将新实例指针分配给实例而另一个线程检查同一变量的情况 - 但我相信在这种情况下它将得到正确处理。

我在这里错过了什么吗？

好吧，不确定操作的重新排序，但在这种情况下，它会改变逻辑，所以我不希望它发生 - 但我不是这个主题的专家。