Linux 资源互斥（同步）方法 --锁和信号量

为什么要有互斥（同步）：多个线程共享资源时，需要确保每个线程看到一致的数据视图，否则可能产生不可预知的结果。

常见的互斥机制如表中所示

睡眠锁和非睡眠锁：

睡眠锁：当thread获取不到锁时，thread进入睡眠，触发调度程序，切换到其他thread，当锁可用时，重新触发调度程序，thread1投入运行，thread1获取锁成功。也就是在锁变得可用时，thread1成功获取到锁时，最少要经过两次的上下文切换，而上下文切换也是占用CPU资源的。

非睡眠锁：当thread获取不到锁时，thread进入自旋，知道锁变得可用，也就是在此期间，CPU一直空转。

那么在可以睡眠的流程中，我们应该怎么选择使用的锁呢？我们已经知道，睡眠锁和非睡眠锁，在锁变得可用前，都是会耗费CPU资源的，睡眠锁是两次的上下文切换浪费CPU，非睡眠锁是自旋浪费时间，因此当我们认为锁在重新变得可用时，那个浪费的时间少，我们就选择哪个锁。所以，一般来讲，对那些共享资源操作较少的任务中，我们选择非睡眠锁，否则，选择睡眠锁。

死锁问题：
1、同一个线程试图对已经加锁的资源进行二次加锁。
2、一个线程在退出时未释放锁，另一个线程在对该锁进行加锁时。
3、两个线程A和B，A对x资源进行了加锁，B对y资源进行了加锁。此时A再想对y加锁时会被阻塞，B想对x进行加锁时会被阻塞。
   这样A永远获取不到x资源的锁，B永远获取不到y资源的锁。

如何避免死锁。
1、一个线程中，避免对已经加锁的资源再次加锁。
2、在线程退出时，一定要释放自身持有的锁。
3、多个线程和多个锁时，必须保证各线程加锁的顺序保持一致。例如，有A和B两个线程，A会操作x,y,z三个资源所，B会操作
y和z两个资源所。如果A加锁的顺序是x,y,z，则B加锁的顺序必须是y,z。如果A加锁的顺序是x,z,y，则B加锁的顺序必须是z,y

中断的锁处理：

中断中无法使用睡眠锁，且使用非睡眠锁也有限制。在中断处理程序中，自旋锁在使用前一定要禁止本地中断，然后再去获取指定的锁。
考虑如下例程：
1、A中断处理程序已经持有锁，并在操作共享资源。
2、来了新的高优先级的中断B，此中断打断了前一个中断，并申请锁。
3、由于A中断已经持有锁，且未释放，因此B中断无法申请到锁，于是只能自旋。
4、由于中断服务程序未完成前，是不会进行调度的，B只能一直自旋，CPU一直在B上空转。

中断中为什么无法使用睡眠锁：

因为调度程序是无法调度中断的，一旦中断因为获取不到锁进入了睡眠，则触发调度程序，CPU切换到其他任务中，则再也无法切换到中断服务任务中，睡眠后续的中断流程无法得到执行。