线程同步——可递归锁和非递归锁

最常见的进程/线程的同步方法有互斥锁(或称互斥量Mutex)，读写锁(rdlock)，条件变量(cond)，信号量(Semophore)等。在Windows系统中，临界区(Critical Section)和事件对象(Event)也是常用的同步方法。

简单地说，互斥锁保护了一个临界区，在这个临界区中，一次最多进入一个线程。如果有多个线程在同一个临界区内活动，就有可能产生竞态(race condition)导致错误
读写锁从广义的逻辑上讲，也可以认为是一种共享版的互斥锁。如果对临界区大部分的操作是读操作而只有少部分是写操作，读写锁在一定程度上能够降低线程互斥产生的代价
条件变量允许线程以一种无竞争的方式去等待某个条件的发生。当该条件没有发生时，线程会一直处于休眠状态，当被其他线程通知条件已经发生时，线程才会被唤醒从而继续向下执行。条件变量是比较底层的同步原语，直接使用的情况不多。使用条件变量的一个经典的例子就是线程池(ThreadPool)了。
在学习操作系统的进程同步原理时，讲的最多的就是信号量了。通过精心设计信号量的PV操作，可以实现很复杂的进程同步情况（例如哲学家进餐问题和理发店问题）。而在现实的程序设计中，却极少有人使用信号量。能用信号量解决的问题似乎总能找到其他更清晰更简洁的设计手段去代替信号量。

本文的目的不是讲解如何使用这些锁，更多的是讲解容易被人忽略的一些关于锁的概念，以及比较经典的使用和设计方法。文章会涉及到递归锁和非递归锁（recursive mutex和non-recursive mutex），区域锁(Scoped Lock)，策略锁(Strategized Lock)，读写锁和条件变量，双重检测锁(DCL)，锁无关的数据结构(Lockng free)，自旋锁等等内容。

一、可递归锁和非递归锁

1. 概念

在所有的线程同步方法中，恐怕互斥锁(mutex)的出场率远远高于其它方法。互斥锁的理解和基本使用方法都很容易，这里不做更多介绍了。

Mutex可以分为递归锁(recursive mutex)和非递归锁(non-recursive mutex)。可递归锁也可称为可重入锁(reentrant mutex)，非递归锁又叫不可重入锁(non-reentrant mutex)。

二者唯一的区别是，同一个线程可以多次获取同一个递归锁，不会产生死锁。而如果一个线程多次获取同一个非递归锁，则会产生死锁。

Windows下的Mutex和Critical Section是可递归的。Linux下的pthread_mutex_t锁默认是非递归的。可以显示的设置PTHREAD_MUTEX_RECURSIVE属性，将pthread_mutex_t设为递归锁。

在大部分介绍如何使用互斥量的文章和书中，这两个概念常常被忽略或者轻描淡写，造成很多人压根就不知道这个概念。但是如果将这两种锁误用，很可能会造成程序的死锁。请看下面的程序。

MutexLock mutex;

void foo()
{
    mutex.lock();
    // do something
    mutex.unlock();
}

void bar()
{
    mutex.lock();
    // do something
    foo();
    mutex.unlock();    
}

foo函数和bar函数都获取了同一个锁，而bar函数又会调用foo函数。如果MutexLock锁是个非递归锁，则这个程序会立即死锁。因此在为一段程序加锁时要格外小心，否则很容易因为这种调用关系而造成死锁。

不要存在侥幸心理，觉得这种情况是很少出现的。当代码复杂到一定程度，被多个人维护，调用关系错综复杂时，程序中很容易犯这样的错误。庆幸的是，这种原因造成的死锁很容易被排除。

但是这并不意味着应该用递归锁去代替非递归锁。递归锁用起来固然简单，但往往会隐藏某些代码问题。比如调用函数和被调用函数以为自己拿到了锁，都在修改同一个对象，这时就很容易出现问题。因此在能使用非递归锁的情况下，应该尽量使用非递归锁，因为死锁相对来说，更容易通过调试发现。程序设计如果有问题，应该暴露的越早越好。

2. 如何避免

为了避免上述情况造成的死锁，AUPE v2一书在第12章提出了一种设计方法。即如果一个函数既有可能在已加锁的情况下使用，也有可能在未加锁的情况下使用，往往将这个函数拆成两个版本---加锁版本和不加锁版本(添加nolock后缀)。

例如将foo()函数拆成两个函数：

// 不加锁版本
void foo_nolock()
{
    // do something
}
// 加锁版本
void fun()
{
    mutex.lock();
    foo_nolock();
    mutex.unlock();
}

为了接口的将来的扩展性，可以将bar()函数用同样方法拆成bar_withou_lock()函数和bar()函数

在Douglas C. Schmidt（ACE框架的主要编写者）的“Strategized Locking, Thread-safe Interface, and Scoped Locking”论文中，提出了一个基于C++的线程安全接口模式(Thread-safe interface pattern)，与AUPE的方法有异曲同工之妙。即在设计接口的时候，每个函数也被拆成两个函数，没有使用锁的函数是private或者protected类型，使用锁的的函数是public类型。接口如下：

class T
{
public:
    foo(); //加锁
    bar(); //加锁
private:
    foo_nolock();
    bar_nolock();
}

作为对外接口的public函数只能调用无锁的私有变量函数，而不能相互调用。在函数具体实现上，这两个方法基本是一样的。

上面讲的两种方法在通常情况下是没问题的，可以有效的避免死锁。但是有些复杂的回调情况下，则必须使用递归锁。比如foo函数调用了外部库的函数，而外部库的函数又回调了bar()函数，此时必须使用递归锁，否则仍然会死锁。AUPE 一书在第十二章就举了一个必须使用递归锁的程序例子。

3. 读写锁的递归性

读写锁（例如linux中的pthread_rwlock_t）提供了一个比互斥锁更加高级别的并发访问。读写锁的实现往往是比互斥锁要复杂的，因此开销也常常大于互斥锁。在我的linux机器上，单纯的写锁的时间开销超差多是互斥锁的10倍左右。

#include <pthread.h>
#include<iostream>

using namespace std;

int main()
{
    pthread_rwlock_t rwl;
    cout << pthread_rwlock_init(&rwl, NULL) << endl;
    cout << pthread_rwlock_rdlock(&rwl) << endl;
    cout << pthread_rwlock_wrlock(&rwl) << endl;
    cout << pthread_rwlock_unlock(&rwl) << endl;
    cout << pthread_rwlock_unlock(&rwl) << endl;
    return -1;
}

先加读锁再加写锁程序会阻塞，那如果先加读锁再加写锁，我们会发现程序奔溃了...

rogn@ubuntu:~/suo$ cat test.cpp
#include <pthread.h>
#include<iostream>

using namespace std;

int main()
{
    pthread_rwlock_t rwl;
    cout << "init: " << pthread_rwlock_init(&rwl, NULL) << endl;
    cout << "write: " << pthread_rwlock_wrlock(&rwl) << endl;
    cout << "read: " << pthread_rwlock_rdlock(&rwl) << endl;    
    cout << "unlock: " << pthread_rwlock_unlock(&rwl) << endl;
    cout << "unlock: " << pthread_rwlock_unlock(&rwl) << endl;
    return -1;
}
rogn@ubuntu:~/suo$ ./test
init: 0
write: 0
read: 35
unlock: 0
Illegal instruction (core dumped)

程序会死锁在接下来的写锁定上. 35错误号为EDEADLK, 意为出现死锁. 仔细研究pthread读写锁的文档, 才发现原来如果一个线程写锁定后, 又调用pthread_rwlock_rdlock函数来读锁定，结果将无法预测。

/*程序3*/
#include <pthread.h>
int main()
{
    pthread_rwlock_t rwl;
    pthread_rwlock_rdlock(&rwl);
    pthread_rwlock_rdlock(&rwl);
    pthread_rwlock_unlock(&rwl);
    pthread_rwlock_unlock(&rwl);
    return -1;
}
/*程序4*/
#include <pthread.h>
int main()
{
    pthread_rwlock_t rwl;
    pthread_rwlock_wrlock(&rwl);
    pthread_rwlock_wrlock(&rwl);
    pthread_rwlock_unlock(&rwl);
    pthread_rwlock_unlock(&rwl);
    return -1;
}

读锁是递归锁（即可重入），写锁是非递归锁（即不可重入）。因此程序3不会死锁，而程序4会一直阻塞。

读写锁是否可以递归会可能随着平台的不同而不同，因此为了避免混淆，建议在不清楚的情况下尽量避免在同一个线程下混用读锁和写锁。

在系统不支持递归锁，而又必须要使用时,就需要自己构造一个递归锁。通常，递归锁是在非递归互斥锁加引用计数器来实现的。简单的说，在加锁前，先判断上一个加锁的线程和当前加锁的线程是否为同一个。如果是同一个线程，则仅仅引用计数器加1。如果不是的话，则引用计数器设为1，则记录当前线程号，并加锁。一个例子可以看这里。需要注意的是，如果自己想写一个递归锁作为公用库使用，就需要考虑更多的异常情况和错误处理，让代码更健壮一些。

原文链接：https://blog.csdn.net/zouxinfox/article/details/5838861

posted @ 2020-04-19 22:26 Rogn 阅读(1547) 评论(0) 编辑收藏举报

刷新页面返回顶部

Rogn

线程同步——可递归锁和非递归锁

一、可递归锁和非递归锁

1. 概念

2. 如何避免

3. 读写锁的递归性

公告