Linux中的spinlock和mutex

内核同步措施

为了避免并发，防止竞争。内核提供了一组同步方法来提供对共享数据的保护。 我们的重点不是介绍这些方法的详细用法，而是强调为什么使用这些方法和它们之间的差别。

Linux 使用的同步机制可以说从2.0到2.6以来不断发展完善。从最初的原子操作，到后来的信号量，从大内核锁到今天的自旋锁。这些同步机制的发展伴随 Linux从单处理器到对称多处理器的过度；伴随着从非抢占内核到抢占内核的过度。锁机制越来越有效，也越来越复杂。
-
 

目前来说内核中原子操作多用来做计数使用，其它情况最常用的是两种锁以及它们的变种:一个是自旋锁，另一个是信号量。我们下面就来着重介绍一下这两种锁机制。

自旋锁

自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分(对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，不需要自旋锁)。

自旋锁最多只能被一个内核任务持有，如果一个内核任务试图请求一个已被争用(已经被持有)的自旋锁，那么这个任务就会一直进行忙循环——旋转——等待锁重新可用。要是锁未被争用，请求它的内核任务便能立刻得到它并且继续进行。自旋锁可以在任何时刻防止多于一个的内核任务同时进入临界区，因此这种锁可有效地避免多处理器上并发运行的内核任务竞争共享资源。

事实上，自旋锁的初衷就是：在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋(特别浪费处理器时间)，所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。

自旋锁的基本形式如下：
    spin_lock(&mr_lock);
    //临界区
    spin_unlock(&mr_lock);

    因为自旋锁在同一时刻只能被最多一个内核任务持有，所以一个时刻只有一个线程允许存在于临界区中。这点很好地满足了对称多处理机器需要的锁定服务。在单处理器上，自旋锁仅仅当作一个设置内核抢占的开关。如果内核抢占也不存在，那么自旋锁会在编译时被完全剔除出内核。
    简单的说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)，它能够在中断上下文中使用。
    死锁：假设有一个或多个内核任务和一个或多个资源，每个内核都在等待其中的一个资源，但所有的资源都已经被占用了。这便会发生所有内核任务都在相互等待，但它们永远不会释放已经占有的资源，于是任何内核任务都无法获得所需要的资源，无法继续运行，这便意味着死锁发生了。自死琐是说自己占有了某个资源，然后自己又申请自己已占有的资源，显然不可能再获得该资源，因此就自缚手脚了。

信号量
    Linux中的信号量是一种睡眠锁。如果有一个任务试图获得一个已被持有的信号量时，信号量会将其推入等待队列，然后让其睡眠。这时处理器获得自由去执行其它代码。当持有信号量的进程将信号量释放后，在等待队列中的一个任务将被唤醒，从而便可以获得这个信号量。
    信号量的睡眠特性，使得信号量适用于锁会被长时间持有的情况；只能在进程上下文中使用，因为中断上下文中是不能被调度的；另外当代码持有信号量时，不可以再持有自旋锁。

信号量基本使用形式为：
static DECLARE_MUTEX(mr_sem);//声明互斥信号量
if(down_interruptible(&mr_sem))
    //可被中断的睡眠，当信号来到，睡眠的任务被唤醒
    //临界区
up(&mr_sem);

信号量和自旋锁区别
    虽然听起来两者之间的使用条件复杂，其实在实际使用中信号量和自旋锁并不易混淆。注意以下原则:
    如果代码需要睡眠——这往往是发生在和用户空间同步时——使用信号量是唯一的选择。由于不受睡眠的限制，使用信号量通常来说更加简单一些。如果需要在自旋锁和信号量中作选择，应该取决于锁被持有的时间长短。理想情况是所有的锁都应该尽可能短的被持有，但是如果锁的持有时间较长的话，使用信号量是更好的选择。另外，信号量不同于自旋锁，它不会关闭内核抢占，所以持有信号量的代码可以被抢占。这意味者信号量不会对影响调度反应时间带来负面影响。

自旋锁对信号量

需求                     建议的加锁方法

低开销加锁               优先使用自旋锁
短期锁定                 优先使用自旋锁
长期加锁                 优先使用信号量
中断上下文中加锁          使用自旋锁
持有锁是需要睡眠、调度     使用信号量

 

因为自旋锁在同一时刻至多被一个执行线程持有，所以一个时刻只能有一个线程位于临界区，这就为多处理器提供了防止并发访问所需的保护机制，但是在单处理器上，编译的时候不会加入自旋锁。它仅仅被当作一个设置内核抢占机制是否被启用的开关。注意，Linux内核实现的自旋锁是不可递归的，这一点不同于自旋锁在其他操作系统中的实现，如果你想得到一个你正持有的锁，你必须自旋，等待你自己释放这个锁，但是你处于自旋忙等待中，所以永远没有机会释放锁，于是你就被自己锁死了，一定要注意！

自旋锁可以用在中断处理程序中，但是在使用时一定要在获取锁之前，首先禁止本地中断（当前处理器上的中断），否则中断处理程序就可能打断正持有锁的内核代码，有可能会试图支争用这个已经被持有的自旋锁。这样一来，中断处理程序就会自旋，等待该锁重新可用，但是锁的持有者在这个中断处理程序执行完毕之前不可能运行，这就会造成双重请求死锁。

自旋锁与下半部：由于下半部（中断程序下半部）可以抢占进程上下文中的代码，所以当下半部和进程上下文共享数据时，必须对进程上下文中的共享数据进行保护，所以需要加锁的同时还要禁止下半部执行。同样，由于中断处理程序可以抢占下半部，所以如果中断处理程序和下半部共享数据，那么就必须在获取恰当的锁的同时还要禁止中断。对于软中断，无论是否同种类型，如果数据被软中断共享，那么它必须得到锁的保护，因为同种类型的两个软中断也可以同进运行在一个系统的多个处理器上。但是，同一个处理器上的一个软中断绝不会抢占另一个软中断，因此，根本不需要禁止下半部。

 

spin_lock_bh通常用在进程中，用来禁止抢断和禁止软中断。

spin_lock_bh()中首先会调用local_bh_disable()禁止当前CPU的软件中断。而函数 spin_unlock_bh()则调用local_bh_enable()来势能本地CPU的软件中断。在软件中断被禁止的时候，本地CPU的所有软中断都不会被执行。

如果一个softirq 与用户上下文共享数据，就有两个问题：首先，当前的用户上下文可能被softirq中断；其次，临界区可能会在别的CPU进入。这时 spin_lock_bh()（include/linux/spinlock.h）就有了用武之地。它会在那个CPU上禁止softirqs，然后获
取 锁。spin_unlock_bh()做相反的工作。（由于历史原因，后缀‘bh’成为对各种下半部的通称，后者是software interrupts的旧称。其实spin_lock_bh本应叫作spin_lock_softirq才贴切），注意这里你也可以用 spin_lock_irq()或者spin_lock_irqsave()，这样不单会禁止softirqs，还会禁止硬件中断。

tasklets 和timer其实是一种softirq，从加锁观点来看，tasklets和timers的地位是等同的。

硬中断通常与一个tasklet或softirq通信。这通常涉及到把一个任务放到某个队列中，再由softirq取出来。如果一个硬件中断服务例程与一个softirq共享数据，就有两点需要考虑。第一，softirq的执行过程可能会被硬件中断打断；第二，临界区可能会被另一个CPU上的硬件中断进入。这正是spin_lock_irq()派上用场的地方。它在那个CPU上禁止中断，然后获取锁。spin_unlock_irq()做相反的工作。

硬件中断服务例程中不需要使用spin_lock_irq()，因为当它在执行的时候softirq是不可能执行的：它可以使用 spin_lock()，这个会更快一些。唯一的例外是另一个硬件中断服务例程使用了相同的锁：spin_lock_irq()会禁止那个硬件中断。