线程同步机制深入分析Word下载.docx
- 文档编号:18952420
- 上传时间:2023-01-02
- 格式:DOCX
- 页数:12
- 大小:22.05KB
线程同步机制深入分析Word下载.docx
《线程同步机制深入分析Word下载.docx》由会员分享,可在线阅读,更多相关《线程同步机制深入分析Word下载.docx(12页珍藏版)》请在冰豆网上搜索。
Linux下的pthread_mutex_t锁默认是非递归的。
可以显示的设置PTHREAD_MUTEX_RECURSIVE属性,将pthread_mutex_t设为递归锁。
在大部分介绍如何使用互斥量的文章和书中,这两个概念常常被忽略或者轻描淡写,造成很多人压根就不知道这个概念。
但是如果将这两种锁误用,很可能会造成程序的死锁。
请看下面的程序。
[cpp]viewplaincopy
1MutexLockmutex;
2
3voidfoo()
4{
5mutex.lock();
6//dosomething
7mutex.unlock();
8}
9
10voidbar()
11{
12mutex.lock();
13//dosomething
14foo();
15mutex.unlock();
16}
foo函数和bar函数都获取了同一个锁,而bar函数又会调用foo函数。
如果MutexLock锁是个非递归锁,则这个程序会立即死锁。
因此在为一段程序加锁时要格外小心,否则很容易因为这种调用关系而造成死锁。
不要存在侥幸心理,觉得这种情况是很少出现的。
当代码复杂到一定程度,被多个人维护,调用关系错综复杂时,程序中很容易犯这样的错误。
庆幸的是,这种原因造成的死锁很容易被排除。
但是这并不意味着应该用递归锁去代替非递归锁。
递归锁用起来固然简单,但往往会隐藏某些代码问题。
比如调用函数和被调用函数以为自己拿到了锁,都在修改同一个对象,这时就很容易出现问题。
因此在能使用非递归锁的情况下,应该尽量使用非递归锁,因为死锁相对来说,更容易通过调试发现。
程序设计如果有问题,应该暴露的越早越好。
1.2如何避免
为了避免上述情况造成的死锁,AUPEv2一书在第12章提出了一种设计方法。
即如果一个函数既有可能在已加锁的情况下使用,也有可能在未加锁的情况下使用,往往将这个函数拆成两个版本---加锁版本和不加锁版本(添加nolock后缀)。
例如将foo()函数拆成两个函数。
17//不加锁版本
18voidfoo_nolock()
19{
20//dosomething
21}
22//加锁版本
23voidfun()
24{
25mutex.lock();
26foo_nolock();
27mutex.unlock();
28}
为了接口的将来的扩展性,可以将bar()函数用同样方法拆成bar_withou_lock()函数和bar()函数。
在DouglasC.Schmidt(ACE框架的主要编写者)的“StrategizedLocking,Thread-safeInterface,andScopedLocking”论文中,提出了一个基于C++的线程安全接口模式(Thread-safeinterfacepattern),与AUPE的方法有异曲同工之妙。
即在设计接口的时候,每个函数也被拆成两个函数,没有使用锁的函数是private或者protected类型,使用锁的的函数是public类型。
接口如下:
29classT
30{
31public:
32foo();
//加锁
33bar();
34private:
35foo_nolock();
36bar_nolock();
37}
作为对外接口的public函数只能调用无锁的私有变量函数,而不能互相调用。
在函数具体实现上,这两种方法基本是一样的。
上面讲的两种方法在通常情况下是没问题的,可以有效的避免死锁。
但是有些复杂的回调情况下,则必须使用递归锁。
比如foo函数调用了外部库的函数,而外部库的函数又回调了bar()函数,此时必须使用递归锁,否则仍然会死锁。
AUPE一书在第十二章就举了一个必须使用递归锁的程序例子。
1.3读写锁的递归性
读写锁(例如Linux中的pthread_rwlock_t)提供了一个比互斥锁更高级别的并发访问。
读写锁的实现往往是比互斥锁要复杂的,因此开销通常也大于互斥锁。
在我的Linux机器上实验发现,单纯的写锁的时间开销差不多是互斥锁十倍左右。
在系统不支持读写锁时,有时需要自己来实现,通常是用条件变量加读写计数器实现的。
有时可以根据实际情况,实现读者优先或者写者优先的读写锁。
读写锁的优势往往展现在读操作很频繁,而写操作较少的情况下。
如果写操作的次数多于读操作,并且写操作的时间都很短,则程序很大部分的开销都花在了读写锁上,这时反而用互斥锁效率会更高些。
相信很多同学学习了读写锁的基本使用方法后,都写过下面这样的程序(Linux下实现)。
38#include<
pthread.h>
39intmain()
40{
41pthread_rwlock_trwl;
42pthread_rwlock_rdlock(&
rwl);
43pthread_rwlock_wrlock(&
44pthread_rwlock_unlock(&
45pthread_rwlock_unlock(&
46return-1;
47}
48
49/*程序2*/
50#include<
51intmain()
52{
53pthread_rwlock_trwl;
54pthread_rwlock_wrlock(&
55pthread_rwlock_rdlock(&
56pthread_rwlock_unlock(&
57pthread_rwlock_unlock(&
58return-1;
59}
你会很疑惑的发现,程序1先加读锁,后加写锁,按理来说应该阻塞,但程序却能顺利执行。
而程序2却发生了阻塞。
更近一步,你能说出执行下面的程序3和程序4会发生什么吗?
60/*程序3*/
61#include<
62intmain()
63{
64pthread_rwlock_trwl;
65pthread_rwlock_rdlock(&
66pthread_rwlock_rdlock(&
67pthread_rwlock_unlock(&
68pthread_rwlock_unlock(&
69return-1;
70}
71/*程序4*/
72#include<
73intmain()
74{
75pthread_rwlock_trwl;
76pthread_rwlock_wrlock(&
77pthread_rwlock_wrlock(&
78pthread_rwlock_unlock(&
79pthread_rwlock_unlock(&
80return-1;
81}
在POSIX标准中,如果一个线程先获得写锁,又获得读锁,则结果是无法预测的。
这就是为什么程序1的运行出人所料。
需要注意的是,读锁是递归锁(即可重入),写锁是非递归锁(即不可重入)。
因此程序3不会死锁,而程序4会一直阻塞。
读写锁是否可以递归会可能随着平台的不同而不同,因此为了避免混淆,建议在不清楚的情况下尽量避免在同一个线程下混用读锁和写锁。
在系统不支持递归锁,而又必须要使用时,就需要自己构造一个递归锁。
通常,递归锁是在非递归互斥锁加引用计数器来实现的。
简单的说,在加锁前,先判断上一个加锁的线程和当前加锁的线程是否为同一个。
如果是同一个线程,则仅仅引用计数器加1。
如果不是的话,则引用计数器设为1,则记录当前线程号,并加锁。
一个例子可以看这里。
需要注意的是,如果自己想写一个递归锁作为公用库使用,就需要考虑更多的异常情况和错误处理,让代码更健壮一些。
下一节,我会介绍一下平时很常见的加锁手段---区域锁(ScopedLocking)技术。
线程同步之利器
(2)——区域锁(Scopedlocking)
什么是区域锁
确切的说,区域锁(Scopedlocking)不是一种锁的类型,而是一种锁的使用模式(pattern)。
这个名词是DouglasC.Schmidt于1998年在其论文ScopedLocking提出,并在ACE框架里面使用。
但作为一种设计思想,这种锁模式应该在更早之前就被业界广泛使用了。
区域锁实际上是RAII模式在锁上面的具体应用。
RAII(ResourceAcquisitionIsInitialization)翻译成中文叫“资源获取即初始化”,最早是由C++的发明者BjarneStroustrup为解决C++中资源分配与销毁问题而提出的。
RAII的基本含义就是:
C++中的资源(例如内存,文件句柄等等)应该由对象来管理,资源在对象的构造函数中初始化,并在对象的析构函数中被释放。
STL中的智能指针就是RAII的一个具体应用。
RAII在C++中使用如此广泛,甚至可以说,不会RAII的裁缝不是一个好程序员。
问题提出
先看看下面这段程序,Cache是一个可能被多个线程访问的缓存类,update函数将字符串value插入到缓存中,如果插入失败,则返回-1。
82Cache*cache=newCache;
83ThreadMutexmutex;
84intupdate(stringvalue)
85{
86mutex.lock();
87if(cache==NULL)
88{
89mutex.unlock();
90return-1;
91}
92If(cache.insert(value)==-1)
93{
94mutex.unlock();
95return-1;
96}
97mutex.unlock();
98return0;
99}
从这个程序中可以看出,为了保证程序不会死锁,每次函数需要return时,都要需要调用unlock函数来释放锁。
不仅如此,假设cache.insert(value)函数内部突然抛出了异常,程序会自动退出,锁仍然能不会释放。
实际上,不仅仅是return,程序中的goto,continue,break语句,以及未处理的异常,都需要程序员检查锁是否需要显示释放,这样的程序是极易出错的。
同样的道理,不仅仅是锁,C++中的资源释放都面临同样的问题。
例如前一阵我在阅读wget源码的时候,就发现虽然一共只有2万行C代码,但是至少有5处以上的return语句忘记释放内存,因此造成了内存泄露。
区域锁的实现
但是自从C++有了有可爱的RAII设计思想,资源释放问题就简单了很多。
区域锁就是把锁封装到一个对象里面。
锁的初始化放到构造函数,锁的释放放到析构函数。
这样当锁离开作用域时,析构函数会自动释放锁。
即使运行时抛出异常,由于析构函数仍然会自动运行,所以锁仍然能自动释放。
一个典型的区域锁
100classThread_Mutex_Guard
101{
102public:
103Thread_Mutex_Guard(Thread_Mutex&
lock)
104:
lock_(&
105{
106//如果加锁失败,则返回-1
107owner_=lock_->
lock();
108}
109
110~Thread_Mutex_Guard(void)
111{
112//如果锁获取失败,就不释放
113if(owner_!
=-1)
114lock_->
unlock();
115}
116private:
117Thread_Mutex*lock_;
118intowner_;
119};
将策略锁应用到前面的update函数如下
120Cache*cache=newCache;
121ThreadMutexmutex;
122intupdate(stringvalue)
123{
124Thread_Mutex_Guard(mutex)
125if(cache==NULL)
126{
127return-1;
128}
129If(cache.insert(value)==-1)
130{
131return-1;
132}
133return0;
134}
基本的区域锁就这么简单。
如果觉得这样锁的力度太大,可以用中括号来限定锁的作用区域,这样就能控制锁的力度。
如下
135{
136Thread_Mutex_Guardguard(&
lock);
137...............
138//离开作用域,锁自动释放
139}
区域锁的改进方案
上面设计的区域锁一个缺点是灵活行,除非离开作用域,否则不能够显式释放锁。
如果为一个区域锁增加显式释放接口,一个最突出的问题是有可能会造成锁的二次释放,从而引发程序错误。
例如
140{
141Thread_Mutex_Guardguard(&
142If(…)
143{
144//显式释放(第一次释放)
145guard.release();
146//自动释放(第二次释放)
147return-1;
148}
149}
为了避免二次释放锁引发的错误,区域锁需要保证只能够锁释放一次。
一个改进的区域锁如下:
150classThread_Mutex_Guard
151{
152public:
153Thread_Mutex_Guard(Thread_Mutex&
154:
155{
156acquire();
157}
158intacquire()
159{
160//加锁失败,返回-1
161owner_=lock_->
162returnowner;
163}
164~Thread_Mutex_Guard(void)
165{
166release();
167}
168intrelease()
169{
170//第一次释放
171if(owner_!
172{
173owner=-1;
174returnlock_->
175}
176//第二次释放
177return0;
178}
179private:
180Thread_Mutex*lock_;
181intowner_;
182};
可以看出,这种方案在加锁失败或者锁的多次释放情况下,不会引起程序的错误。
缺点:
区域锁固然好使,但也有不可避免的一些缺点
(1)对于非递归锁,有可能因为重复加锁而造成死锁。
(2)线程的强制终止或者退出,会造成区域锁不会自动释放。
应该尽量避免这种情形,或者使用一些特殊的错误处理设计来确保锁会释放。
(3)编译器会产生警告说有变量只定义但没有使用。
有些编译器选项甚至会让有警告的程序无法编译通过。
在ACE中,为了避免这种情况,作者定义了一个宏如下
#defineUNUSED_ARG(arg){if(&
arg)/*null*/;
}
使用如下:
183Thread_Mutex_Guardguard(lock_);
184UNUSED_ARG(guard);
这样编译器就不会再警告了。
扩展阅读:
小技巧--如何在C++中实现Java的synchronized关键字
借助于区域锁的思想,再定义一个synchronized宏,可以在C++中实现类似Java中的synchronized关键字功能。
链接:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 线程 同步 机制 深入 分析