ACE中的Double Checked Locking 模式.docVIP

ACE中的Double Checked Locking 模式 (作者:Douglas C. Schmidt ,by huihoo.org CORBA课题 Thzhang 译 , Allen整理,制作) 意图 无论什么时候当临界区中的代码仅仅需要加锁一次，同时当其获取锁的时候必须是线程安全的，可以用Double Checked Locking 模式来减少竞争和加锁载荷。 动机 1、标准的单例。开发正确的有效的并发应用是困难的。程序员必须学习新的技术（并发控制和防止死锁的算法）和机制（如多线程和同步API）。此外，许多熟悉的设计模式（如单例和迭代子）在包含不使用任何并发上下文假设的顺序程序中可以工作的很好。为了说明这点，考虑一个标准的单例模式在多线程环境下的实现。单例模式保证一个类仅有一个实例同时提供了全局唯一的访问这个实例的入口点。在c++程序中动态分配单例对象是通用的方式，这是因为c++程序没有很好的定义静态全局对象的初始化次序，因此是不可移植的。而且，动态分配避免了单例对象在永远没有被使用情况下的初始化开销。 class Singleton { public: static Singleton *instance (void) { if (instance_ == 0) // Critical section. instance_ = new Singleton; return instance_; } void method (void); // Other methods and members omitted. private: static Singleton *instance_; }; 应用代码在使用单例对象提供的操作前，通过调用静态的instance方法来获取单例对象的引用，如下所示： Singleton::instance ()-method (); 2、问题：竞争条件。不幸的是，上面展示的标准单例模式的实现在抢先多任务和真正并行环境下无法正常工作。例如，如果在并行主机上运行的多个线程在单例对象初始化之前同时调用Singleton::instance方法，Singleton的构造函数将被调用多次，这是因为多个线程将在上面展示的临界区中执行new singleton操作。临界区是一个必须遵守下列定式的指令序列：当一个线程/进程在临界区中运行时，没有其他任何线程/进程会同时在临界区中运行。在这个例子中，单例的初始化过程是一个临界区，违反临界区的原则，在最好的情况下将导致内存泄漏，最坏的情况下，如果初始化过程不是幂等的（idempotent.），将导致严重的后果。 3、 通常的陷阱和弊端。实现临界区的通常方法是在类中增加一个静态的Mutex对象。这个Mutex保证单例的分配和初始化是原子操作，如下： class Singleton { public: static Singleton *instance (void) { // Constructor of guard acquires lock_ automatically. Guard guard (lock_); // Only one thread in the critical section at a time. if (instance_ == 0) instance_ = new Singleton; return instance_; // Destructor of guard releases lock_ automatically. } private: static Mutex lock_; static Singleton *instance_; }; guard类使用了一个c++的习惯用法，当这个类的对象实例被创建时，它使用构造函数来自动获取一个资源，当类对象离开一个区域时，使用析构器来自动释放这个资源。通过使用guard，每一个对Singleton::instance方法的访问将自动的获取和释放lock_。 即使这个临界区只是被使用了一次，但是每个对instance方法的调用都必须获取和释放lock_。虽然现在这个实现是线程安全的，但过多的加锁负载是不能被接受的。一个明显（虽然不正确）的优化方法是将guard放在针对instance进行条件检测的内部： static Singleton *instance (void) { if (instance_ == 0) { Guard guard (lock_); // Only come here if instance_ hasnt been initialized yet. instance_ = new Singleton; } return instanc