Double Checked Locking 模式 -- 单例实现的多线程版本

之前在使用Double Check Locking 模式时，发现自己还是不太理解。于是写个记录,其实很简单,一看就明白了。
应用特别说明:
1.Double Check Locking模式是singleton的多线程版本，如果是单线程则应使用singleton。
2.Double Check Locking模式依就会使用锁——临界区锁定，不要以为可以避免使用锁。
3.Double Check Locking 解决的问题是:当多个线程存在访问临界区企图时，保证了临界区只需要访问一次。
下面是其适用特点:
1.多个线程试图并发访问一个临界区;
2.临界区只需执行一次;
分析如下3种方法：
//class singleton
//:s1-
singleton* get_instance(void)
{
lock();
if( instance == 0) {
instance = new singleton;
}
unlock();
return instance;
}
**存在的问题是：无论是否已经初始化都要加锁,增加了负荷,已经没有所谓的并发性能了。
//:s-2
singleton* get_instance(void)
{
if( instance == 0){
lock();
instance = new singleton;
unlock();
}
return instance;
}
**存在的问题是：不能保证临界区只初始化一次,没能实现singleton的基本功能;
//:s-3
singleton* get_instance(void)
{
if( instance == 0){
lock();
if( instance == 0 )
instance = new singleton;
unlock();
}
return instance;
}
**解决路上述问题——双检锁模式。

 

最近觉得把double check 模式仅仅理解成singleton的多线程版本限制了他的应用。下面谈一下我的一些理解。
现实生活中对于一种临界资源，我们常常采取的方式是事先了解一下他的使用情况，然后再决定是等待还是离开。比如去图书馆借书前我们会先了解一下需要的书是否在馆内，去饭店吃饭我们会先问一下有没有位子等等。尽管即使事先我们了解了情况，去了之后却发现仍有别人比我们先来一步，但是这是合乎情理的，起码我们还有些希望。
在多线程环境中，一个线程就是一个消费者对象，让一个不知情的线程等待是不合理的。按照面向对象的思想，这里正是使用double check的时机！
if(!no_room()){
lock();
if(!no_room()){
use_it();
}
unlock();
}
这样不是更拟人化一点么，更重要的是这样的应用场合几乎随处可见！
~end~

转自：http://blog.csdn.net/wwsoon/article/details/1485886