【Linux多线程编程】5. 线程锁（2）——死锁、读写锁

前言

上篇文章【Linux多线程编程】4. 线程锁（1）——互斥锁 我们介绍了线程同步的其中一种方式——互斥锁，互斥锁也可以理解为独占锁，只要有一个线程拿到该锁，其他的线程想要获取只能阻塞等待。但互斥锁的使用不当也可能会导致一些问题，比如死锁。本篇文章将介绍死锁以及另一种线程同步方式——读写锁。

死锁

典型死锁问题——银行家死锁

死锁发生在线程争夺锁的过程中，一个比较典型的案例就是银行家死锁问题，银行家死锁的问题的描述如下图所示：

五个人坐在一起吃饭，但是吃饭需要同时持有刀叉才可以，每个人持有资源如下
1号：持有刀，请求叉
2号：持有叉，请求刀
3号：持有叉，请求刀
4号：持有刀，请求叉
5号：持有叉，请求刀

但是现场只有3把 叉，2把刀；每个人都在请求另一半资源，但每个人都不肯放下自己持有的资源，所以盘子里的饭都没动:)
这是典型的一种死锁情况，死锁的原因就是每个人都持有一半资源，请求另一半资源，但没有人肯放下自己的资源。
有没有办法解决呢？显然，只要其中一个人愿意先放下自己持有的资源，让别人获取到，获取到的那个人就可以吃饭，用完资源后释放，其他的人就可以竞争到资源最后每个人都吃完。核心就是释放已有的资源。
另一种方法就是规定资源获取的顺序，如果每个人都先拿刀，再拿叉，就一定有一个人会先同时持有刀叉，然后就可以继续运转起来。核心是规定资源获取的顺序。

互斥锁使用不当引起的死锁问题

上面叙述的是正常使用锁情况下，资源竞争不当引发的死锁问题。还有一些不注意时会引发的死锁问题，更为常见，如下场景

1. 加锁后未释放
2. 对同一把锁重复加锁

场景一可能是如下的代码：

pthread_mutex_t mutex;
for (int i = 0; i < 100; ++i)
{
    pthread_mutex_lock(&mutex);
 
    //共享资源
    ...
    // 此处没有释放锁
}

场景二可能是如下代码：

pthread_mutex_t mutex;
void* func()
{
    pthread_mutex_lock(&mutex);
    //共享资源
    ...
    // 未释放锁前重复加锁
    pthread_mutex_lock(&mutex); // 重复加锁
}

当然这样的代码很明显，一眼就能看出来，实际开发中，最最可能出现的就是跨函数调用的加解锁，即如下代码示例：

pthread_mutex_t mutex;
void* funcA()
{
    pthread_mutex_lock(&mutex);
    //共享资源
    ...
    pthread_mutex_unlock(&mutex); // 重复加锁
}
void* funcB()
{
    pthread_mutex_lock(&mutex);
    //共享资源
    ...
	funcA(); // 调用 funcA，funcA中再次对 mutex 加锁，造成重复加锁，funcA 加不上锁阻塞，导致死锁
    pthread_mutex_unlock(&mutex); // 重复加锁
}

这段代码，单独看每个函数都没有问题，但是一旦运行起来必定死锁，所以实际开发中要检查函数的调用栈，确保上下级调用不会有重复加锁的问题。

读写锁

读写锁场景

如果多个线程同时访问临界资源的时候，但只对其进行读取的操作，并不进行修改，这个时候使用互斥锁让所有线程排队读取的效率就不高了。

在对数据的读写操作中，更多的是读操作，写操作较少，例如对数据库数据的读写应用。为了满足当前能够允许多个读出，但只允许一个写入的需求，线程提供了读写锁来实现。

就好比在淘宝买东西，一百个人同时想查一下某个商品还有多少库存，这个时候如果一个人正在查的时候其他人就不能查，效率就会很低。

读写锁介绍

读写锁是一种特殊的互斥锁，如果一个线程想要读取临界资源就加读锁，想要修改临界资源就加写锁。

这里分为四种情况：

线程A想对临界资源X加读锁，X已被其他线程加了读锁，此时线程A加读锁成功
线程A想对临界资源X加读锁，X已被其他线程加了写锁，此时线程A加读锁失败
线程A想对临界资源X加写锁，X已被其他线程加了读锁，此时线程A加读锁失败
线程A想对临界资源X加写锁，X已被其他线程加了写锁，此时线程A加读锁失败

读写锁的使用在下篇进行介绍