[原] blade中singleton的实现

标签：

最近看了龚大大KalyGE中的singleton, 觉得非常不错(C++中线程安全并且高效的singleton).

可惜blade的代码都是C++03的, 没有使用C++11的任何特性. 笔者对于singleton也有些经验, 不过由于业余写代码本来就时间不够(blade在6年内堆了近20W行代码), 所以笔记记得非常少. 最近几个月业余没有写代码了, 所以有时间把blade在开发中遇到的问题贴出来.

而C++11虽然很爽很方便, 但是目前还没有加入支持的打算.

为了方便分析, 列出两种方式的singleton实现:

简单实现 (local static object):

1 template<typename T> class Singleton
2 {
3     static T& getSingleton()
4     {
5         static T instance;
6         return instance;
7     }
8 };

复杂实现( double check lock):

 1 static T* msSingleton = NULL;
 2 static Lock msLock;
 3 
 4 T& getSingleton()
 5 {
 6     if (NULL == msSingleton )
 7     {
 8         ScopeLock lock(msLock);
 9         if (NULL == msSingleton )
10         {
11             msSingleton = new T;
12         }
13     }
14      return *msSingleton;
15 }

下面两种实现, 称为简单模式和复杂模式, 并基于C++03标准分析.

1.定义和限制

singleton顾名思义, 就是单例, 所以不能有多个实例, 也不能复制. 笔者曾在工作中就遇到过新手类似下面的复制:

1 A a = A::getSingleton();

即便是老鸟, 也难以保证不会有手抖的时候. 这种问题可以在runtime做检查. 不过在编译期排除错误更好: 把ctor, copy  ctor设为私有, 同时把operator new设置为protected.

然而有时候为了更加灵活, 允许singleton的一次性new, 比如数据加载时, 统一用new创建对象, 又比如, Singleton的MFC类, MFC在nc destroy的时候, 会自动delete this, 那么要求对象必须new出来

这些情况,可以考虑允许operator new, 并加上runtime check.

2.多线程

多线程的问题, 龚大大已经说的很详细了, 这里不多说了.

因为没有使用C++11, 目前blade的singleton使用的是double check lock, 可惜还没有加memory barrier, 考虑后面可能会加上.

对于多线程来说, 个人还是认为, singleton应该在程序初始化时就构建好, 这样可以简化singleton的实现.

3.构造和析构顺序

先贴以下笔者之前的笔记:

http://wenzhang.baidu.com/page/view?key=0f256d18fe5d14a2-1426750048

http://wenzhang.baidu.com/page/view?key=f06f2a30029f88ef-1426750071

而对于#pragma init_seg这种东西暂时忽略, 因为如果可以通过标准定义可以解决, 那么跨平台和移植性就有保证, 所以尽量不考虑compiler pragma.

对于静态变量的初始化/销毁顺序, 这里就不引用C++03标准的原文了, 简单描述如下:

• 单个编译单元内的静态变量, 按顺序初始化
• 不同编译单元内的静态变量, 初始化顺序是不确定的
• 函数内的局部静态变量, 在第一次执行到变量定义的时候,执行初始化
• 所有静态变量的析构顺序与构造顺序相反, 逆序执行

贴两个blade在开发中遇到的问题:

问题a: 初始化

 1 class A : Singleton<A> {};
 2 class B
 3 {
 4     B()
 5     {
 6         A::getSingleton().xxxx();
 7     }
 8 };
 9 
10 static B b;

以上情况对于简单模式的singleton没有问题, 单例A会在第一次调用时初始化.
但是对于复杂模式呢?

注意Singleton<A>::msSingleon和b都是静态变量. 对于模板来说, 模板实例化的位置不确定, 不知道在哪个编译单元, 所以可以认为::b和::Singleton<A>::msSingleton的初始化顺序是不确定的.

当b先于Singleton<A>::msSingleton初始化的时候, 由于b的构造调用的A的singleton lazy init,  而后, ::Singleton<A>::msSingleton又接着初始化, 根据用户定义

1 static T* msSingleton = NULL;

将Singleton<A>::msSingleton指针清空! 这是lazy init在指针初始化之前, 给指针赋值了, 不用去查标准如何定义该行为, 很明显在逻辑上已经错了.

解决方法是不指定initializer, 这样local static的对象只会被清零(zero-initialization), 而且是最先执行清零, 而后不再被赋值.  (C++03: 6.7 Declaration statement: 4).

1  static T* msSingleton;

题外: C++的NULL被定义为0, 所以清零没有问题. 而且指针可以被隐式转换为bool, 所以C++是鼓励用户使用if( ptr )的, 而C没有明确规定NULL的值, 甚至在某些机器上, NULL 不是0.所以if(ptr)对于C来说就"呵呵"了.而blade的代码全部是C++, 但全使用类似if( ptr == NULL )的格式, 这个只是习惯而已. 当然理论上(NULL == ptr)更好.

问题b: 析构

然而再看下面的情况:

1 class A: Singelton<A> {}
2 class B: Singleton<B>
3 {
4     ~B()
5     {
6         A::getSingleton().xxxx();
7     }
8 };

B在析构时依赖了A, 所以必须要求A在B之前构造. 但是由于lazy init的原因, 方便嘛, 可能使用的时候就很随意, 导致没有控制初始化顺序, 那么析构顺序也不对了.

但对于简单模式的Singleton, 至少顺序还是能控制的:

1 B::getSingleton().xxxx();  //lazy init of B
2 ...
3 A::getSingleton().xxxx(); //lazy init of A

把上面的代码改为:

1 A::getSingleton();         //force (explicit) init of A,B: A must construct before B
2 B::getSingleton();
3 ...
4 
5 B::getSingleton().xxxx();
6 ...
7 A::getSingleton().xxxx();
8 ...

这样A在B之前初始化, 所以A能够在B之后析构.

而对于复杂模式的Singlton, 因为使用的是指针. 为了完成lazy de-init, 将msSingleton, 改为智能指针, 这样可以自动析构. 同样为了解决问题a, 这个智能指针不能有initializer.

然而, 不同的singleton内的静态变量, 由于其初始化顺序用户无法控制, 所以析构顺序根本无法控制,成了硬伤.

分析: 简单模式(local static object)的单例, 至少是可以控制析构顺序的, 而复杂模式(double check lock), 直接成了硬伤. 那么把简单模式应用到复杂模式, 会怎么样?

local static smart pointer:

 1 T* msSingleton;
 2 
 3 T& getSingleton()
 4 {
 5     if (NULL == msSingleton )
 6     {
 7         static Lock msLock;
 8         ScopeLock lock(msLock);
 9         if (NULL == msSingleton )
10         {
11             static SMART_PTR<T> p;
12             p = new T;
13             msSingleton = p;
14         }
15     }
16      return *msSingleton;
17 }

由于local static smart pointer的存在, 就可以控制lazy de-init的顺序了. 这种模式对于问题a和问题b都可以解决顺序问题. 对于问题b, 因为初始化顺序比较随意, 除非事先仔细分析, 否则要等析构出问题了才能修复.

然而lazy init就是为了方便, 使程序员可以不管这些细节, 集中精力做业务逻辑. 所以等出了问题再改也不是不能接受. 至少析构顺序是可控制的, 而不像之前, 那么痛苦的根本不能控制顺序.

为了方便检测问题b, 不至于崩溃在深层调用后, 还要费神查看调用栈, 加上一个assert提前拦截到错误就可以了.

 1 T* msSingleton;
 2  
 3 ~Singleton()
 4 {
 5     msSingleton = NULL;
 6 }
 7 
 8 T& getSingleton()
 9 {
10     if (NULL == msSingleton )
11     {
12         static bool isCreated = false;
13         assert( isCreated == false ); //avoid create for the second time, this usually happens when singleton construction order need explicit control
14 
15         static Lock msLock;
16         ScopeLock lock(msLock);
17         isCreated = true;
18         if (NULL == msSingleton )
19         {
20             static SMART_PTR<T> p;
21             p = new T;
22             msSingleton = p;
23          }
24      }
25      return *msSingleton;
26 }

在这种情况下, Singleton析构时msSington会被清空. 如果之后还有调用, 那么就会触发assertion failure.

因为这种情况非常少, blade至今遇到过3-5次, 如果遇到了, 调整一下调用顺序, 或则按上面问题b的处理方式, 提前显式调用一次, 强制初始化就可以了.

上面的两个问题是blade的singleton在开发中遇到的典型问题, 理论上可能还有其他问题没有记录, 或者没有遇到也没有解决, 但是俗话说, 车到山前必有路, 总会有个解决方案的, 比如修改设计和实现等等.

只要singleton的初始化顺序是用户(程序猿)可控的, 而不是无序执行, 用户无法控制, 问题都好说.

比如在问题a中, 如果也有析构的依赖: A在B之后析构.那么要求A在B之前构造, 可以多加一个静态变量:

class A : Singleton<A> {}
class B
{
    B()
    {
        A::getSingleton().xxxx();
    }
    ~B()
    {
        A::getSingleton().yyyy();
    }
};

template <typename T> class SingletonInitializer
{
    SingletonInitializer()
    {
        T::getSingleton();
    }
};

static SingletonInitializer<A> c;
static B b;

4. 动态库(.DLL/.so)的导出

如果Singleton没有用模板, 那么这个问题可以忽略. 如果使用了模板, 那么就得考虑动态库导出的问题了, 这个问题可以转化为模板类的导出问题:
[原]DLL导出实例化的模板类

GCC对于MSVC, 区别比较大, 细节先不写了, 主要的原理和思路笔者在这中间提到一些:

[原]跨平台编程注意事项(三): window 到 android 的 移植

具体细节有空了再补上.

5.内存模型

singleton 需要考虑内存管理吗? 绝大多数情况都不需要. 然而对于笔者这样一个完美主义的强迫症来说, 一想到lazy init的singleton在程序运行的任何时间, 都有可能申请一块内存(第一次初始化时), 并且永不释放, 就心里别扭.

会不会产生内存碎片? 理论上会.

一种方式是在double check lock的内部, 仍然使用local static object, 而不使用local static smart pointer, 这样静态变量的内存不是动态分配(堆内存), 不需要特殊的管理. 这种方式最简单, 也是目前blade使用的方案.

 1 //note: DO NOT specify a initializer for it
 2 //Otherwise some early lazy initialization will be overwritten by initializer.
 3 T* msSingleton;
 4 
 5 Singleton()
 6 {
 7     assert(msSingleton == NULL );
 8     msSingleton = static_cast<T*>(this);
 9 }
10  
11 ~Singleton()
12 {
13     msSingleton = NULL;
14 }
15 
16 T& getSingleton()
17 {
18     if (NULL == msSingleton )
19     {
20         static bool isCreated = false;
21          assert( isCreated = false ); //avoid create for the second time, this usually happens when singleton construction order need explicit control
22 
23         static Lock msLock;
24         ScopeLock lock(msLock);
25         isCreated = true;
26         if (NULL == msSingleton )
27         {
28             static volatile T p;
29             assert( msSingleton == &p );
30          }
31      }
32      return *msSingleton;
33 }

如果是local static smart pointer, 那么需要动态分配, 由于blade已经有static memory pool, 所以这里也用上了, 将singleton 对象占用的内存, 放在static memory pool中. 不过缺点是, 这样让singleton的实现变得又更加复杂了...

 虽然看起来并不是那么复杂:

1 template<typename T> class Singleton : public StaticAllocatable
2 {
3 ...
4 };

 不过前面也提到了, 即便使用local static object, 但是singleton也有可能是new出来的, 如果这种情况允许, 虽然情况不多, 加上内存管理会更好. 这样即便使用smart pointer也没有问题了.

singleton的内存管理思路, 是基于生命周期的内存管理, 笔者在另一个博客也简单提了思路:

[原]基于内存生命周期的内存管理

显然static memory不是为singleton专门设计的, 它的用处也不止于此, 比如游戏的database, 等等各种静态数据, 都可以放入static pool中去. singleton只是享受了一下便利罢了.

还比如对应的还有标准容器扩展, 只要实现了符合std标准的allocator就可以了. 比如staticvector, staticmap static set等等.

不过内存管理是另一个巨话题, 这里不能多说了, 否则又将是另一个长篇大论了.

6.抽象单例

Abstract/Interface Singleton

[原] blade中singleton的实现

标签：

原文地址：http://www.cnblogs.com/crazii/p/4512110.html