线程同步机制深入分析VIP免费

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