线程同步机制深入分析.docVIP

线程同步之利器⑴——可递归锁与非递归锁 概述 最常见的进程/线程的同步方法有互斥锁(或称互斥量Mutex),读写 锁(rdlock),条件变量(cond),信号量(Semophore)等。在Windows系统 中，临界区(Critical Section)和事件对象(Event)也是常用的同步方法。 简单的说，互斥锁保护了一个临界区，在这个临界区中，一次最多 只能进入一个线程。如果有多个进程在同一个临界区内活动，就有可能 产生竞态条件(race condition)导致错误。 读写锁从广义的逻辑上讲，也可以认为是一种共享版的互斥锁。如 果对一个临界区大部分是读操作而只有少量的写操作，读写锁在一定程 度上能够降低线程互斥产牛的代价。 条件变量允许线程以一种无竞争的方式等待某个条件的发生。当该 条件没有发生时，线程会一直处于休眠状态。当被其它线程通知条件已 经发生时，线程才会被唤醒从而继续向下执行。条件变量是比较底层的 同步原语，直接使用的情况不多，往往用于实现高层之间的线程同步。 使用条件变量的一个经典的例子就是线程池(Thread Pool)To 在学习操作系统的进程同步原理时，讲的最多的就是信号量了。通 过精心设计信号量的PV操作，可以实现很复杂的进程同步情况(例如 经典的哲学家就餐问题和理发店问题)。而现实的程序设计中，却极少 有人使用信号量。能用信号量解决的问题似乎总能用其它更清晰更简洁 的设计手段去代替信号量。 本系列文章的目的并不是为了讲解这些同步方法应该如何使用 (AUPE的书已经足够清楚了)。更多的是讲解很容易被人忽略的一些 关于锁的概念，以及比较经典的使用与设计方法。文章会涉及到递归锁 与非递归锁 (recursive mutex 和 non-recursive mutex), 区域锁(Scoped Lock),策略锁(Strategized Locking),读写锁与条件变量，双重检测锁 (DCL),锁无关的数据结构(Locking free),自旋锁等等内容，希望能够 抛砖引玉。 那么我们就先从递归锁与非递归锁说开去吧：) 1可递归锁与非递归锁 1.1概念 在所有的线程同步方法中，恐怕互斥锁(mutex)的出场率远远高于 其它方法。互斥锁的理解和基木使用方法都很容易，这里不做更多介绍 To Mutex 可以分为递妇鲍recursive mutex)^^^/^^(non-recursive mutex)o可递归锁也可称为可童人埶reentrant mutex),非递归锁又叫 不可重入锁goo-reentrant mutex)o 二者唯一的区别是，同一个线程可以多次获取同一个递归锁，不会 产生死锁。而如果一个线程多次获取同一个非递归锁，则会产生死锁。 Windows 下的 Mutex 和 Critical Section 是可递归的。Linux 下的 pthread_mutex_t锁默认是非递归的。可以显示的设置 PTHREAD MUTEX RECURSIVE 属性，W pthread mutex t 设为递 归锁。 在大部分介绍如何使用互斥量的文章和书中，这两个概念常常被忽 略或者轻描淡写，造成很多人压根就不知道这个概念。但是如果将这两 种锁误用，很可能会造成程序的死锁。请看下面的程序。 MutexLock mutex; 2 void foo() { mutex.lock(); // do something 7 mutex.uniock(); 8 } 9 1() void bar() 11 { 12 mutex.lock(); 13 // do something 14 1=00()； 15 mutex.unlock(); 16 } foo函数和bar函数都获取了同一个锁，而bar函数又会调用foo函 数。如果MutexLock锁是个非递归锁，则这个程序会立即死锁。因此 在为一段程序加锁时要格外小心，否则很容易因为这种调用关系而造成 死锁。 不要存在侥幸心理，觉得这种情况是很少岀现的。当代码复杂到一 定程度，被多个人维护，调用关系错综复杂时，程序中很容易犯这样的 错误。庆幸的是，这种原因造成的死锁很容易被排除。 但是这并不意味着应该用递归锁去代替非递归锁。递归锁用起来固 然简单，但往往会隐藏某些代码问题。比如调用函数和被调用函数以为 自己拿到了锁，都在修改同一个对象，这时就很容易岀现问题。因此在 能使用非递归锁的情况下，应该尽量使用非递归锁，因为死锁相对来说, 更容易通过调试发现。程序设计如果有问题，应该暴露的越早越好。 1.2如何避免 为了避免上述情况造成的死锁，AUPE V2—书在第12章提出了一种 设计方法。即如果一个函数既有可能在已加锁的情况下使用，也有可能 在未加锁的情况下使用，往往将这个函数拆成