Singleton、MultiThread、Lib——实现单实例无锁多线程安全API

    前阵子写静态lib导出单实例多线程安全API时，出现了CRITICAL_SECTION初始化太晚的问题，之后查看了错误的资料，引导向了错误的理解，以至于今天凌晨看到另一份代码，也不多想的以为singletone double check会出bug，本文做下记录备忘。

   相关知识点：Singleton Double Check、多线程下的局部Static对象、静态Lib中的全局对象、无锁编程。

一、singleton double check

SingleInstance* volatile g_instance = NULL;
cswuyg::MyCritical g_cs;
SingleInstance* GetInstance()
{
    if (g_instance == NULL)
    {
        cswuyg::Lock<> lock(g_cs);
        if (g_instance == NULL)
        {
            g_instance = new SingleInstance;
        }
    }
    return g_instance;
}

    这样的代码在vs2005 IDE下（不考虑全局对象的初始化）没有问题。之前只略看他人的文章，不思考，误以为：g_instance = new SingleInstance ; 这句在线程A的执行会被线程B g_instance == NULL的判断打断，导致线程B返回的g_instance是一个半成品。实际上不会，因为volatile保证了指令的执行顺序，g_instance的赋值是在内存分配、构造函数执行之后做的，而且赋值是原子操作，完全没有问题。

    特别注意，g_instance变量必须加上volatile。

    volatile一般有两个好处：1是使得多个线程直接操作内存，变量被某个线程改变后其它线程也可以及时看到改变后的值；2是阻止编译器优化操作volatile变量的指令执行顺序。这里如果不使用它，就可能导致编译器调整汇编指令的顺序，分配完内存就直接把地址赋值给g_instance指针，后面再调用构造函数，它这样调整的理由可能是这样子：分配到的内存指针在后续的执行中没有被修改，先赋值给g_instance和晚赋值给g_instance没有区别，这就导致了半成品对象的产生。

    volatile还有另外的好处。除了关注编译器优化之外，还需要关注CPU的指令顺序调整，必须阻止它。vs2005以后的编译器对volatile关键字做了CPU层面的支持，使用了acquire、release、fence语义，所以使用volatile可以解决编译器的优化和CPU的指令调整问题。而vs2005之前的编译器，则需要使用原子操作对g_instance赋值，或者是使用MemoryBarrier宏，这是CPU指令的支持。

补充1：

MemoryBarrier方面的资料：

http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming

http://stackoverflow.com/questions/23359265/is-memory-barrier-needed-in-this-situation-or-just-a-volatile

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

上边都强调了volatile跟MemoryBarrier不一样~ 但仅限于非MSVC环境。

下面是来自MDSN的资料：

msdn上搜索memory barrier可以发现这篇文章：

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684208(v=vs.85).aspx
MemoryBarrier宏
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686355(v=vs.85).aspx
这篇文章表示，vs2005以后的volatile已经包含了memory barrier的功能，并介绍了有几类函数是不会被调换执行顺序的。
http://stackoverflow.com/questions/19652824/why-can-memorybarrier-be-implemented-as-a-call-to-xchg/19652910#19652910
它介绍了为什么x86机器上的xchg可以消灭掉CPU的reorder。

《程序员的自我修养》一书在第一章的科普部分也谈到了过度优化的问题，谈及volatile和barrier。

二、导出Lib中慎用全局对象 & 原子操作代替锁

    我的Lib的导出API提供的数据只需要获取一次就够了，不能多次获取，所以它必须是单实例的、多线程安全的，再考虑到不能浪费频繁的锁消耗，很直接的做法便是用singleton double check。

    首先我选择使用临界区实现锁，而临界区在API被调用之前需要先初始化，于是定义一个Lock封装了临界区的初始化，什么时候初始化？必须是全局对象，如果为定义局部static对象会导致多线程不安全。

    static对象不是多线程安全的：

    从上图的汇编指令可以看到static对象的构造函数是否被执行的判断逻辑：

1、通过标识值判断是否该执行构造函数（这里的构造函数内联了）；

2、执行构造函数，首先把标志值置位。

     有可能多个线程都同时通过了1的判断，导致构造函数被多次执行。

     使用了全局对象之后发现也不可行：导出函数依赖全局对象的初始化，虽然全局对象会在main函数之前初始化，但初始化时机还是可能太晚了，譬如这种情况：lib的使用者也定义了全局对象，并且初始化得更早，使用者的全局对象构造函数里调用了lib的导出函数，导出函数使用了还没初始化的临界区全局对象导致崩溃，更麻烦的是，使用者的dump捕获机制是在main函数里初始化的，生效得太晚，导致dump无法捕获，使这个crash更加隐蔽。C++的全局对象应该尽量少用。exe里面如果使用了全局对象，则需要保证dump捕获机制对所有的代码都生效。

    既然临界区初始化问题无法解决，局部static对象、全局对象都无法使用，需要找到一个不需要初始化又能实现锁的方法：那就是原子操作。

    单纯的原子操作并没有锁的功能，需要配合上：if + while + Sleep（当然，也可以说是if + while，不去Sleep也可以）。回头网上一搜索，这里的原子操作，也是各种“无锁XX”实现的根基，无锁XX，让我重新发明了一回。

代码如下：

SingleInstance* volatile g_instance;
LONG volatile g_for_lock; 

SingleInstance* GetInstance()
{
    if (g_instance == NULL)
    {
        LONG pre_value = ::InterlockedExchange(&g_for_lock, );
        if (pre_value != )
        {
            while(g_instance == NULL)
            {
                ::Sleep();
            }
        }
        if (g_instance == NULL)
        {
            g_instance = new SingleInstance;
        }
    }
    return g_instance;
}

　　全局的g_for_lock在PE文件装入内存时就初始化为0，所以不存在初始化问题；InterlockedExchange 适用于xp、win7、win8，不存在系统限制；多个线程同时调用InterlockedExchange，只能有一个线程得到0，保证只初始化一次，其余线程进入while循环等待，直到g_point非空。问题不逼你，你就不会想到还有这么好的实现思路 :)

使用原子操作还可以很容易的实现临界区锁的功能，这里就不说了。

补充2：

有时候，是否我们并不需要去考虑多线程？譬如，我让singleton对象只在main函数执行之前生成，这时候只能是单线程的，但要慎重，因为全局对象带来的问题可能比singleton double check要麻烦很多。对于我这次的lib来说，是不能保证singleton对象一定在main函数执行之前使用的，所以这个解决方案无法实施。

三、PE文件中的Lib库全局变量

    像上边定义的全局变量，如果DLL和EXE都使用这个lib，它们各自有一份独立的全局变量。

 

本文所在：http://www.cnblogs.com/cswuyg/p/3575022.html 

Double Check 相关资料（主要是说执行指令调整导致在多核机器上某个线程会返回半成品对象，导致DoubleCheck思路失效）：

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

http://zh.wikipedia.org/wiki/%E5%8F%8C%E9%87%8D%E6%A3%80%E6%9F%A5%E9%94%81%E5%AE%9A%E6%A8%A1%E5%BC%8F

2014.3.8补充：

抛出异常问题：对于导出API还需要注意不能影响到使用者进程的运行，所以不能抛出exception，需要这么做：1、在API实现处，使用__try...__except把所有逻辑封起来；2、在API的入口处设置非法参数、纯虚函数调用错误处理（_invalid_parameter_handler、_set_purecall_handler），并在出口处还原以便不修改外界设置，这里要解决的是CRT抛出的错误，它跟SEH没关系，所以使用__try...__except无法catch住，这两函数的相关知识参考：《windows下的dump捕获》http://www.cnblogs.com/cswuyg/p/3207576.html。

2014.3.13补充：

编译依赖问题：EXE C依赖Lib B，Lib B依赖Lib A，如果Lib A使用了预编译，那么会出现这种链接错误：error LNK2011: precompiled object not linked in; image may not run，有两种解决方案：1、让EXE C能接触到Lib A工程，保证EXE C在链接的时候能找到Lib A所有相关的中间产物，这个方案我不能采用，因为对外提供的只是Lib B SDK，不是源码；2、Lib A不使用预编译，这个方案比较方便，不过不使用预编译后会增加编译时间，由于Lib A工程比较小，可以接受。 另外，Lib B如何包含Lib A的问题可以参考：http://www.cnblogs.com/cswuyg/archive/2012/02/03/2336424.html