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~

转自：/article/11613308.html