深入理解linux内核自旋锁

最近在内核频繁使用了自旋锁，自旋锁如果使用不当，极易引起死锁，在此总结一下。

自旋锁是一个互斥设备，它只有两个值：“锁定”和“解锁”。它通常实现为某个整数值中的某个位。希望获得某个特定锁得代码测试相关的位。如果锁可用，则“锁定”被设置，而代码继续进入临界区；相反，如果锁被其他人获得，则代码进入忙循环（而不是休眠，这也是自旋锁和一般锁的区别）并重复检查这个锁，直到该锁可用为止，这就是自旋的过程。“测试并设置位”的操作必须是原子的，这样，即使多个线程在给定时间自旋，也只有一个线程可获得该锁。

自旋锁最初是为了在多处理器系统（SMP）使用而设计的，但是只要考虑到并发问题，单处理器在运行可抢占内核时其行为就类似于SMP。因此，自旋锁对于SMP和单处理器可抢占内核都适用。可以想象，当一个处理器处于自旋状态时，它做不了任何有用的工作，因此自旋锁对于单处理器不可抢占内核没有意义，实际上，非抢占式的单处理器系统上自旋锁被实现为空操作，不做任何事情。

自旋锁有几个重要的特性：1、被自旋锁保护的临界区代码执行时不能进入休眠。2、被自旋锁保护的临界区代码执行时是不能被被其他中断中断。3、被自旋锁保护的临界区代码执行时，内核不能被抢占。从这几个特性可以归纳出一个共性：被自旋锁保护的临界区代码执行时，它不能因为任何原因放弃处理器。

考虑上面第一种情况，想象你的内核代码请求到一个自旋锁并且在它的临界区里做它的事情，在中间某处，你的代码失去了处理器。或许它已调用了一个函数（copy_from_user，假设）使进程进入睡眠。也或许，内核抢占发威，一个更高优先级的进程将你的代码推到了一边。此时，正好某个别的线程想获取同一个锁，如果这个线程运行在和你的内核代码不同的处理器上（幸运的情况），那么它可能要自旋等待一段时间（可能很长），当你的代码从休眠中唤醒或者重新得到处理器并释放锁，它就能得到锁。而最坏的情况是，那个想获取锁得线程刚好和你的代码运行在同一个处理器上，这时它将一直持有CPU进行自旋操作，而你的代码是永远不可能有任何机会来获得CPU释放这个锁了，这就是悲催的死锁。

考虑上面第二种情况，和上面第一种情况类似。假设我们的驱动程序正在运行，并且已经获取了一个自旋锁，这个锁控制着对设备的访问。在拥有这个锁得时候，设备产生了一个中断，它导致中断处理例程被调用，而中断处理例程在访问设备之前，也要获得这个锁。当中断处理例程和我们的驱动程序代码在同一个处理器上运行时，由于中断处理例程持有CPU不断自旋，我们的代码将得不到机会释放锁，这也将导致死锁。

因此，如果我们有一个自旋锁，它可以被运行在（硬件或软件）中断上下文中的代码获得，则必须使用某个禁用中断的spin_lock形式的锁来禁用本地中断（注意，只是禁用本地CPU的中断，不能禁用别的处理器的中断），使用其他的锁定函数迟早会导致系统死锁（导致死锁的时间可能不定，但是发生上述死锁情况的概率肯定是有的，看处理器怎么调度了）。如果我们不会在硬中断处理例程中访问自旋锁，但可能在软中断（例如，以tasklet的形式运行的代码）中访问，则应该使用spin_lock_bh，以便在安全避免死锁的同时还能服务硬件中断。

补充：

锁定一个自旋锁的函数有四个：

void spin_lock(spinlock_t *lock);      

最基本得自旋锁函数，它不失效本地中断。

void spin_lock_irqsave(spinlock_t *lock, unsigned long flags);

在获得自旋锁之前禁用硬中断（只在本地处理器上），而先前的中断状态保存在flags中

void spin_lockirq(spinlock_t *lock);

在获得自旋锁之前禁用硬中断（只在本地处理器上），不保存中断状态

void spin_lock_bh(spinlock_t *lock);

在获得锁前禁用软中断，保持硬中断打开状态