C++11 中的双重检查锁定模式

双重检查锁定模式(DCLP)在无锁编程方面是有点儿臭名昭著案例学术研究的味道。直到2004年，使用java开发并没有安全的方式来实现它。在 c++11之前，使用便捷式c+开发并没有安全的方式来实现它。由于引起人们关注的缺点模式暴露在这些语言之中，人们开始写它。一组高调的java聚集在 一起开发人员并签署了一项声明，题为：“双重检查锁定坏了”。在2004年斯科特 、梅尔斯和安德烈、亚历山发表了一篇文章，题为：“c+与双重检查锁定 的危险”对于DCLP是什么？这两篇文章都是伟大的引物，为什么呢？在当时看来，这些语言都不足以实现它。

在过去。java现在可以为修订内存模型，为thevolatileeyword注入新的语义，使得它尽可然安全实现DCLP.同样地，c+11有一个全 新的内存模型和原子库使得各种各样的便捷式DCLP得以实现。c+11反过来启发Mintomic,一个小型图书馆，我今年早些时候发布的，这使得它尽可 能的实现一些较旧的c/c++编译器以及DCLP.

在这篇文章中，我将重点关注c++实现的DCLP.

什么是双重检查锁定？

假设你有一个类，它实现了著名的Singleton 模式，现在你想让它变得线程安全。显然的一个方法就是通过增加一个锁来保证互斥共享。这样的话，如果有两个线程同时调用了Singleton::getInstance，将只有其中之一会创建这个单例。

Singleton* Singleton::getInstance() { Lock lock; // scope-based lock, released automatically when the function returns if (m_instance == NULL) { 
        m_instance = new Singleton; 
    } return m_instance; 
} 

这是完全合法的方法，但是一旦单例被创建，实际上就不再需要锁了。锁不一定慢，但是在高并发的条件下，不具有很好的伸缩性。

双重检查锁定模式避免了在单例已经存在时候的锁定。不过如Meyers-Alexandrescu的论文所显示的，它并不简单。在那篇论文中，作者描述了几个有缺陷的用C++实现DCLP的尝试，并剖析了每种情况为什么是不安全的。最后，在第12页，他们给出了一个安全的实现，但是它依赖于非指定的，特定平台的内存屏障(memory barriers)。

(译注：内存屏障就是一种干预手段. 他们能保证处于内存屏障两边的内存操作满足部分有序)

Singleton* Singleton::getInstance() {  
    Singleton* tmp = m_instance; ... // insert memory barrier if (tmp == NULL) {  
        Lock lock;  
        tmp = m_instance; if (tmp == NULL) {  
            tmp = new Singleton; ... // insert memory barrier m_instance = tmp;  
        }  
    } return tmp;  
}  

这里，我们可以发现双重检查锁定模式是由此得名的：在单例指针m_instance为NULL的时候，我们仅仅使用了一个锁，这个锁使偶然访问到该单例的第一组线程继续下去。而在锁的内部，m_instance被再次检查，这样就只有第一个线程可以创建这个单例了。

这与可运行的实现非常相近。只是在突出显示的几行漏掉了某种内存屏障。在作者写这篇论文的时候，还没有填补此项空白的轻便的C/C++函数。现在，C++11已经有了。

用 C++11 获得与释放屏障

你可以用获得与释放屏障 安全的完成上述实现，在我以前的文章中我已经详细的解释过这个主题。不过，为了让代码真正的具有可移植性，你还必须要将m_instance包装成原子类型，并且用放松的原子操作（译注：即非原子操作）来操作它。这里给出的是结果代码，获取与释放屏障部分高亮了。

std::atomic<Singleton*> Singleton::m_instance; 
std::mutex Singleton::m_mutex; 
 
Singleton* Singleton::getInstance() { 
    Singleton* tmp = m_instance.load(std::memory_order_relaxed); std::atomic_thread_fence(std::memory_order_acquire); if (tmp == nullptr) { 
        std::lock_guard<std::mutex> lock(m_mutex); 
        tmp = m_instance.load(std::memory_order_relaxed); if (tmp == nullptr) { 
            tmp = new Singleton; std::atomic_thread_fence(std::memory_order_release); m_instance.store(tmp, std::memory_order_relaxed); 
        } 
    } return tmp; 
} 

即使是在多核系统上，它也可以令人信赖的工作，因为内存屏障在创建单例的线程与其后任何跳过这个锁的线程之间，创建了一种同步的关系。Singleton::m_instance充当警卫变量，而单例本身的内容充当有效载荷。

使用 Mintomic 屏障

Mintomic 是一个小型的C语言的库，它提供了C++11原子库的一个功能子集，其中包含有获取与释放屏障，而且它是运行于更老的编译器之上的。Mintomic依赖于这样的假设 ，即C++11的内存模型——特殊的是，其中包括无中生有的存储 ——因为它不被更老的编译器支持，不过这已经是我们不通过C++11能做到的最佳程度了。记住这些东西可是若干年来我们在写多线程C++代码时的环境。无 中生有的存储（Out-of-thin-air stores）已被时间证明是不流行的，而且好的编译器也基本上不会这么做。

这里有一个DCLP的实现，就是用Mintomic来获取与释放屏障的。和前面使用C++11获取和释放屏障的例子比起来，它基本上是等效的。

mint_atomicPtr_t Singleton::m_instance = { 0 }; 
mint_mutex_t Singleton::m_mutex; 
 
Singleton* Singleton::getInstance() { 
    Singleton* tmp = (Singleton*) mint_load_ptr_relaxed(&m_instance); mint_thread_fence_acquire(); if (tmp == NULL) { 
        mint_mutex_lock(&m_mutex); 
        tmp = (Singleton*) mint_load_ptr_relaxed(&m_instance); if (tmp == NULL) { 
            tmp = new Singleton; mint_thread_fence_release(); mint_store_ptr_relaxed(&m_instance, tmp); 
        } 
        mint_mutex_unlock(&m_mutex); 
    } return tmp; 
} 

#p#

使用c++ 11低级排序约束

C++11的获取与释放屏障可以正确的实现DCLP，而且应该能够针对当今大多数的多核设备，生成优化的机器代码（就像Mintomic做的那样），但是它们似乎不是非常时髦。在C++11中获得同等效果的首选方法，应该是使用基于低级排序约束的原子操作。正如我先前所说，一条写释放(write-release)可以同步于一条读获取(read-acquire)。

std::atomic<Singleton*> Singleton::m_instance; 
std::mutex Singleton::m_mutex; 
 
Singleton* Singleton::getInstance() { Singleton* tmp = m_instance.load(std::memory_order_acquire); if (tmp == nullptr) { 
        std::lock_guard<std::mutex> lock(m_mutex); 
        tmp = m_instance.load(std::memory_order_relaxed); if (tmp == nullptr) { 
            tmp = new Singleton; m_instance.store(tmp, std::memory_order_release); } 
    } return tmp; 
} 

从技术上说，这种无锁的同步形式，比使用独立屏障的形式，要不那么严格；上面的操作只是意味着阻止它们自己周围的内存重新排序，这与独立的屏障不同，后者意味着阻止所有相邻的操作的特定类型的内存重排序。尽管如此，在x86/64, ARMv6/v7,以及 PowerPC架构上，对于这两种形式,可能的最好代码都是相同的。例如，在一篇早前文章中，我演示了在ARMv7编译器上，C++11低级排序约束是如何发送dmb指令的，而这也正是你在使用独立屏障时所期待的同样事情。

使用 C++11的顺序一致原子

C++11提供了一种完全不同的方法来写无锁代码。（我们可以认为在某些特定的代码路径上DCLP是“无锁”的，因为并不是所有的线程都具有锁。）如果在 所有原子库函数上，你忽略了可选的std::memory_order参数，那么默认值std::memory_order_seq_cst就会将所有的 原子变量转变为顺序一致的(sequentially consistent) (SC)原子。通过SC原子，只要不存在数据竞争，整个算法就可以保证是顺序一致的。SC原子Java 5+中的volatile变量非常相似。

这里是使用SC原子的一个DCLP实现。如之前所有例子一样，一旦单例被创建，第二行高亮将与第一行同步。

std::atomic<Singleton*> Singleton::m_instance; 
std::mutex Singleton::m_mutex; 
 
Singleton* Singleton::getInstance() { Singleton* tmp = m_instance.load(); if (tmp == nullptr) { 
        std::lock_guard<std::mutex> lock(m_mutex); 
        tmp = m_instance.load(); if (tmp == nullptr) { 
            tmp = new Singleton; m_instance.store(tmp); } 
    } return tmp; 
} 

SC原子被认为可以使程序员更容易思考。其代价是生成的机器代码似乎比之前的例子效率要低。例如，这里有有一些关于上面代码清单的x64机器代码，由Clang 3.3在启用代码优化的条件下生成：

由于我们使用了SC原子，保存到m_instance是由xchg指令实现的，在x64上它具有内存屏障作用。这比x64中DCLP实际需要的指令更强。 只需一条简单的mov指令就可以做这项工作。不过这并不十分要紧，因为在单例首次创建的代码路径上，xchg指令只下发一次。

另一方面，如果你给PowerPC 或 ARMv6/v7编译SC原子指令，你十有八九会得到糟糕的机器代码。其中的细节，请看Herb Sutter的atomic<> 武器说话,第 2部分的00:44:25 - 00:49:16段落。

使用 C++11 的数据相关性排序

在上面所有我给出的例子中，在创建单例的那个线程，与其后任何越过锁的线程之间，有一种同步的关系。警卫变量就是单例指针，有效载荷是单例自身的内容。在本例中，有效载荷被认为是警卫指针的一个相关性数据。

人们后来发现，当存在数据相关性时，上面所有例子中都用到的读获取（read-acquire）操作，将极富杀伤力！我们用消费操作（consume operation）来替代它要好一点。消费操作很酷，因为它们消除了PowerPC中的一条lwsync指令，以及ARMv7中的一条dmb指令。在将来的一篇文章中，我将更多的谈论到有关数据相关性和消费操作的内容。

使用C++11中的静态初始化器

有些读者已经知道这篇文章的妙语：如果你想得到一个线程安全的实例，C++11不允许你跳过以上的所有步骤。你可以简单使用一个静态初始化器。

Singleton& Singleton::getInstance() {  
    static Singleton instance; return instance; 
} 

让我们回到6.7.6节查看C++11的标准：

由编译器来临时代替实现的细节，DCLP明显是一个不错的选择。不能保证编译器将会使用DCLP,但一些（也许更多）却碰巧发生了。使用the-std=c++0x选项对ARM进行编译,生成了下面的一些机器码，这些机器码是由GCC 4.6生成的。

原文链接：http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

译文链接：http://www.oschina.net/translate/double-checked-locking-is-fixed-in-cpp11