singleton模式深度分析

volatile语义及线程安全singleton模式探讨

 

转自：http://www.cnblogs.com/rocketfan/archive/2009/12/05/1617759.html

作者：Scott Meyers and Andrei Alexandrescu   译者： ChengHuige at gmail.com

1.引言 

详尽的讨论了volatile语义以及如何用C++实现线程安全的Singleton模式。 

主要参考Scott Meyers and Andrei Alexandrescu写的“C++ and the Perils of Double-Checked Locking”，这是2004年的文章，以及网上的其他资源。 

其他参考：

 

• Threads Basics 

        http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/threadsintro.html

•  The "Double-Checked Locking is Broken" Declaration

　　  http://www.cs.umd.edu/%7Epugh/java/memoryModel/DoubleCheckedLocking.html 

 

• 非完美C++ Singleton实现[2]  Ismayday的官方技术博客

        http://hi.baidu.com/ismayday/blog/item/a797d6cae24b0d41f21fe788.html

 

 

•  《C++0x漫谈》系列之：多线程内存模型By 刘未鹏(pongba)

        http://blog.csdn.net/pongba/archive/2007/06/20/1659952.aspx

 

 

• 一个老外的博客，包括需不需要对int加锁，gcc中的原子变量操作

        http://www.alexonlinux.com/ 

 

 

 

在前面我写了一个使用c++0x STL自带的多线程API的示例http://www.cnblogs.com/rocketfan/archive/2009/12/02/1615093.html

而这里涉及的不是多线程库的API，因为几乎所有的多线程互斥同步问题都可以通过互斥锁mutex和条件变量解决。但是频繁的加锁解锁很耗时，

毕竟用多线程就是要速度，本文涉及的都是相关的与线程库无关的问题。  

2.多线程问题简介

　　一个 多线程的程序允许多个线程同时运行，可能要允许它们访问及更新它们共享的变量，每个线程都有其局部变量但是所有的线程都会看到同样的全局变量或者，“static"静态的类成员变量。

 　　不同的线程可能会运行在同一个处理器上，轮流执行（by interleaving execution).也有可能会运行在不同处理器上，所谓的hardware thread现在很常见。 

 3.volatile变量是什么

这个网上有很多介绍但都没有全面解释。而在“C++ and the Perils of Double-Checked Locking”的附注，作者给出了详细全面的解释。

作者是从volatile的产生讲起的，当时是为了统一的使用相同的地址处理内存地址和IO port地址,所谓memory-mapped I/O (MMIO）。

个人觉得本质都是不同层次存储映射关系吧，类比寄存器和内存。下面都用寄存器和内存解释。

 

• 读的情况  

 

unsigned int *p = GetMagicAddress();

unsigned int a, b;

a = *p

b = *p; 

 考虑上面的代码，假设GetMagicAddress()是获得内存的地址，那么a = *p, b = *p，会被编译器认为是相同的操作，假设a = *p 使得值缓存在寄存器中，那么为了速度优化，编译器可能会将最后一行的代码换成

b = a;

 这样就不去内存读而是直接去寄存器读但这可能并不是我们想要的，因为如果这期间其他的线程改写了内存中*P的内容呢？

thread1             thread2 

a = *p;

                       *p = 3

b = a  //---------- 编译器优化的结果使得我们读到的并不是最新的p所指的内存的值

 

• 写的情况

*p = a;

*p = b;

 

向上面的代码，编译器可能会认为*p = a是冗余操作从而去掉它，而这也可能不是我们想要的。

 

volatile的作用 ：

volatile exists for specifying special treatment for such locations, specifically:

(1) the content of a volatile variable is “unstable” (can change by means unknown to the compiler),

(2) all writes to volatile data are “observable” so they must be executed religiously, and

(3) all operations on volatile data are executed in the sequence in which they appear in the source code.

1. 被声明为volatile的变量其内容是不稳定的(unstable),它的值有可能由编译器所不能知晓的情况所改变。
2. 所有对声明为volatile的变量的写操作都是可见的，必须严格执行be executed religiously。
3. 所有对声明为volatile的变量的操作（读写）都必须严格按照源代码的顺序执行。

所以上面的第一条确保读正确，第二条确保写正确，第三条确保读写混合的情况正确。JAVA更进一步跨越线程保证上面的条件。而C/C++只对单一线程内部保证。刘未鹏在博客中这么解释：“总而言之，由于C++03标准是单线程的，因此volatile只能保证单线程内语意。对于前面的那个例子，将x和y设为volatile只能保证分别在Thread1和Thread2中的两个操作是按代码顺序执行的，但并不能保证在Thread2“眼里”的Thread1的两个操作是按代码顺序执行的。也就是说，只能保证两个操作的线程内次序，不能保证它们的线程间次序。一句话，目前的volatile语意是无法保证多线程下的操作的正确性的。” 

 

但是即使是JAVA能够跨越线程保证，仍然是不够的因为volatile和非volatile操作之间的顺序仍然是未定义的，有可能产生问题，考虑下面的代码：

volatile int vi;

void bar(void) {
vi = 1;
foo();
vi = 0;
}

我们一般会认为vi会在调用foo之前设置为1,调用完后会被置为0。然而编译器不会对你保证这一点，它会很高兴的将你的foo()移位，比如跑到vi = 1前面，只要它知道在foo()里不会涉及到其它的volatile操作。所以安全的方法是用栅栏memory barrier例如“asm volatile (”" ::: “memory”)加到foo的前面和后面 来保证严格的执行顺序。

Meyers提到由于上面的原因我们通常会需要加大量的volatile变量，java1.5中的volatile给出了更严格简单的定义，所有对volatile的读操作，都将被确保发生在该语句后面的读写(any memory reference volatile or not)操作的前面。而写操作则保证会发生在该语句前面的读写操作的后面。.NET也定义了跨线程的volatile语意。

4.线程安全的C++ singleton模式

 

• 最简单的singleton

注：下面有些来自原文，有些来自"非完美Singleton实现"，其它参考之3。

 

代码

 1  // from the header file
 2  class Singleton {
 3  public:
 4  static Singleton* instance();
 5  ...
 6  private:
 7  static Singleton* pInstance;
 8  };
 9 
10  // from the implementation file
11  Singleton* Singleton::pInstance = 0;
12 
13  Singleton* Singleton::instance() {
14  if (pInstance == 0) {
15     pInstance = new Singleton;
16  }
17  return pInstance;
18  }

 

如果在单线程模式那么上面的代码除了instance()可能会有异常安全问题外没有太大问题。但是对于多线程而言，如果两个线程在14判断都读到pInstance = 0同时进入15，那么就会产生两个Singleton对象。而pInstance指向后产生的那一个。

 

•  加锁保护的singleton

代码

1 Singleton* Singleton::instance() {
2     Lock lock; // acquire lock (params omitted for simplicity)
3     if (pInstance == 0) {
4         pInstance = new Singleton;
5     }
6     return pInstance;
7 } // release lock (via Lock destructor)

 

 

 

这样是绝对的安全了，但是由于加锁解锁的代价大，而instance又是可能被频繁调用的函数所以大大影响性能。事实上只要pInstance == 0的时候才可能出现问题，需要加锁，那么有了下面的写法：代码

1 Singleton* Singleton::instance() {
2     if (pInstance == 0) {
3         Lock lock; // acquire lock (params omitted for simplicity)
4         pInstance = new Singleton;
5     }
6     return pInstance;
7 } // release lock (via Lock destructor)

 

但是这样是错误的，因为两个线程如果同时在2判断为true，虽然会在3处互斥，但是还是会轮流进入保护区，生成两个Singleton.于是有人想到下面的方法。

 

• DCL方法（Double Checked  Locking)

这也是ACE中Singleton的实现方法：

 

 代码

1 Singleton* Singleton::instance() {
2     if (pInstance == 0) { // 1st test
3         Lock lock;
4         if (pInstance == 0) { // 2nd test
5             pInstance = new Singleton;
6         }
7     }
8     return pInstance;
9 }

 

这看上去很完美但是它也是有问题的

在编译器未优化的情况下顺序如下：
1.new operator分配适当的内存；
2.在分配的内存上构造Singleton对象；
3.内存地址赋值给_instance。

但是当编译器优化后执行顺序可能如下：
1.new operator分配适当的内存；
2.内存地址赋值给_instance；

3.在分配的内存上构造Singleton对象。

 编译器优化后的代码看起来像下面这样：

 代码

 1 Singleton* Singleton::instance() {
 2     if (pInstance == 0) {
 3         Lock lock;
 4         if (pInstance == 0) {
 5             pInstance = // Step 3
 6               operator new(sizeof(Singleton)); // Step 1
 7             new (pInstance) Singleton; // Step 2
 8          }
 9     }
10     return pInstance;
11 }

 

 这样如果一个线程按照编译器优化的顺序执行到5,这时后pInstance就已经非0了，而实际上它所指向的内存上Singleton对象还没有被构造，这个时候有可能另一个线程运行到2,发现pInstance不是0,NULL，于是return pInstance,假设它又用这个指向还未构造对象的指针调用pInstance->doSomeThing() .........：（

 

 未了避免这种情况，于是有了下面的做法

 代码

 1 Singleton* Singleton::instance() {
 2      if (pInstance == 0) {
 3          Lock lock;
 4          if (pInstance == 0) {
 5               Singleton* temp = new Singleton; // initialize to temp
 6               pInstance = temp; // assign temp to pInstance
 7          }
 8      }
 9      return pInstance;
10 }

 

企图利用一个临时变量，仅当Singleton对象构造完成后才把地址赋给pInstance,然而很不幸，编译器会把你的临时变量视为无用的东西从而优化掉。。。。 

这里插一句为什么用pthread之类的库能够解决问题，保证顺序，因为它们是非语言本身的，往往 强迫编译器产生与之适应的代码，往往会调用系统调用，很多是用汇编实现的。

 

• 加入volatile

前面讲到volatile的定义，那么这里能否利用volatile呢。上面最后的代码想法不错，只是编译器会捣乱：）那么我们加入volatile来避免编译器的优化,保证语句的顺序执行。不过这里我们考虑这种情况，Singlton带有一个变量x,默认的私有构造函数会将其赋值为5.

 

代码

 1 class Singleton {
 2  public:
 3      static Singleton* instance();
 4      ...
 5  private:
 6      static Singleton* volatile pInstance; // volatile added
 7      int x;
 8      Singleton() : x(5) {}
 9  };
10  
11  // from the implementation file
12  Singleton* Singleton::pInstance = 0;
13  
14  Singleton* Singleton::instance() {
15      if (pInstance == 0) {
16          Lock lock;
17          if (pInstance == 0) {
18              Singleton* volatile temp = new Singleton; // volatile added
19              pInstance = temp;
20          }
21      }
22      return pInstance;
23 }

 

 

下面考虑编译器inline构造函数和之后的instance()函数的样子

 代码

1 if (pInstance == 0) {
2     Lock lock;
3     if (pInstance == 0) {
4         Singleton* volatile temp =
5         static_cast<Singleton*>(operator new(sizeof(Singleton)));
6         temp->x = 5; // inlined Singleton constructor
7         pInstance = temp;
8     }
9 }

 

问题出来了，尽管temp被声明为volatile,但是*temp不是，这意味着temp->x也不是，这意味着编译器可能会把6,7句换位置，从而使得另一个线程得到一个指向x域并未被构造好的Sigleton对象！

解决办法是我们不仅仅声明pInstance为volatile也将*pInstance声明为volatile.如下：

代码

 1 class Singleton {
 2 public:
 3     static volatile Singleton* volatile instance();
 4     ...
 5 private:
 6     // one more volatile added
 7     static Singleton* volatile pInstance;
 8 };
 9 
10 // from the implementation file
11 volatile Singleton* volatile Singleton::pInstance = 0;
12 volatile Singleton* volatile Singleton::instance() {
13     if (pInstance == 0) {
14         Lock lock;
15         if (pInstance == 0) {
16             // one more volatile added
17