自旋锁
自旋锁
------------------------------------------------------
自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分(对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，不需要自旋锁)。
自旋锁最多只能被一个内核任务持有，如果一个内核任务试图请求一个已被争用(已经被持有)的自旋锁，那么这个任务就会一直进行忙循环——旋转——等待锁重新可用。要是锁未被争用，请求它的内核任务便能立刻得到它并且继续进行。自旋锁可以在任何时刻防止多于一个的内核任务同时进入临界区，因此这种锁可有效地避免多处理器上并发运行的内核任务竞争共享资源。
事实上，自旋锁的初衷就是：在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋(特别浪费处理器时间)，所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。
自旋锁的基本形式如下：
spin_lock(&mr_lock);
//临界区
spin_unlock(&mr_lock);
因为自旋锁在同一时刻只能被最多一个内核任务持有，所以一个时刻只有一个线程允许存在于临界区中。这点很好地满足了对称多处理机器需要的锁定服务。在单处理器上，自旋锁仅仅当作一个设置内核抢占的开关。如果内核抢占也不存在，那么自旋锁会在编译时被完全剔除出内核。
简单的说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)，它能够在中断上下文中使用。
死锁：假设有一个或多个内核任务和一个或多个资源，每个内核都在等待其中的一个资源，但所有的资源都已经被占用了。这便会发生所有内核任务都在相互等待，但它们永远不会释放已经占有的资源，于是任何内核任务都无法获得所需要的资源，无法继续运行，这便意味着死锁发生了。自死琐是说自己占有了某个资源，然后自己又申请自己已占有的资源，显然不可能再获得该资源，因此就自缚手脚了。
IRQL概念仅能解决单CPU上的同步问题，在多处理器平台上，它不能保证你的代码不被运行在其它处理器上的代码所干扰。一个称为自旋锁(spin lock)的原始对象可以解决这个问题。为了获得一个自旋锁，在某CPU上运行的代码需先执行一个原子操作，该操作测试并设置(test-and-set)某个内存变量，由于它是原子操作，所以在该操作完成之前其它CPU不可能访问这个内存变量。如果测试结果表明锁已经空闲，则程序获得这个自旋锁并继续执行。如果测试结果表明锁仍被占用，程序将在一个小的循环内重复这个“测试并设置(test-and-set)”操作，即开始“自旋”。最后，锁的所有者通过重置该变量释放这个自旋锁，于是，某个等待的test-and-set操作向其调用者报告锁已释放。
关于自旋锁有两个明显的事实。第一，如果一个已经拥有某个自旋锁的CPU想第二次获得这个自旋锁，则该CPU将死锁(deadlock)。自旋锁没有与其关联的“使用计数器”或“所有者标识”；锁或者被占用或者空闲。如果你在锁被占用时获取它，你将等待到该锁被释放。如果碰巧你的CPU已经拥有了该锁，那么用于释放锁的代码将得不到运行，因为你使CPU永远处于“测试并设置”某个内存变量的自旋状态。
关于自旋锁的另一个事实是，CPU在等待自旋锁时不做任何有用的工作，仅仅是等待。所以，为了避免影响性能，你应该在拥有自旋锁时做尽量少的操作，因为此时某个CPU可能正在等待这个自旋锁。
关于自旋锁还存在着一个不太明显但很重要的事实：你仅能在低于或等于DISPATCH_LEVEL级上请求自旋锁，在你拥有自旋锁期间，内核将把你的代码提升到DISPATCH_LEVEL级上运行。在内部，内核能在高于DISPATCH_LEVEL的级上获取自旋锁，但你和我都做不到这一点。
自旋锁最多只能被一个可执行线程持有。自旋锁不会引起调用者睡眠，如果一个执行线程试图获得一个已经被持有的自旋锁，那么线程就会一直进行忙循环，一直等待下去，在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。
由于自旋锁使用者一般保持锁时间非常短，因此选择自旋而不是睡眠是非常必要的，自旋锁的效率远高于互斥锁。
信号量和读写信号量适合于保持时间较长的情况，它们会导致调用者睡眠，因此只能在进 程上下文使用（_trylock的变种能够在中断上下文使用）；而自旋锁适合于保持时间非常短的情况，因为一个被争用的自旋锁使得请求它的线程在等待重新 可用时自旋，特别浪费处理时间，这是自旋锁的要害之处，所以自旋锁不应该被长时间持有。在实际应用中自旋锁代码只有几行，而持有自旋锁的时间也一般不会超 过两次上下方切换，因线程一旦要进行切换，就至少花费切出切入两次，自旋锁的占用时间如果远远长于两次上下文切换，我们就可以让线程睡眠，这就失去了设计 自旋锁的意义。
如果被保护的共享资源只在进程上下文访问，使用信号量保护该共享资源非常合适，如果对共享资源的访问时间非常短，自旋锁也可以。但是如果被保护的共享资源需要在中断上下文访问（包括底半部即中断处理句柄和顶半部即软中断），就必须使用自旋锁。
自旋锁保持期间是抢占失效的，而信号量和读写信号量保持期间是可以被抢占的。自旋锁只有在内核可抢占或SMP的情况下才真正需要，在单CPU且不可抢占的内核下，自旋锁的所有操作都是空操作。
一个执行单元要想访问被自旋锁保护的共享资源，必须先得到锁，在访问完共享资源后，必须释放锁。如果在获取自旋锁时，没有任何执行单元保持该锁，那么将立即得到锁；如果在获取自旋锁时锁已经有保持者，那么获取锁操作将自旋在那里，直到该自旋锁的保持者释放了锁。
无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。自旋锁的实现和体系结构密切相关，代码一般通过汇编实现，定义在文件,实际用到的接口定义在文件夹 中, 自旋锁的API有：
|
CODE:spin_lock_init(x) |
该宏用于初始化自旋锁x。自旋锁在真正使用前必须先初始化。该宏用于动态初始化指定的。
|
CODE:DEFINE_SPINLOCK(x) |
该宏声明一个自旋锁x并初始化它。该宏在2.6.11中第一次被定义，在先前的内核中并没有该宏。
|
CODE:SPIN_LOCK_UNLOCKED |
该宏用于静态初始化一个自旋锁。
|
CODE:DEFINE_SPINLOCK(x)等同于spinlock_t x = SPIN_LOCK_UNLOCKEDspin_is_locked(x) ) |
该宏用于判断自旋锁x是否已经被某执行单元保持（即被锁），如果是，返回真，否则返回假。
|
CODE:spin_unlock_wait(x) |
该宏用于等待自旋锁x变得没有被任何执行单元保持，如果没有任何执行单元保持该自旋锁，该宏立即返回，否则将循环在那里，直到该自旋锁被保持者释放。
|
CODE:spin_trylock(lock) |
该宏尽力获得自旋锁lock，如果能立即获得锁，它获得锁并返回真，否则不能立即获得锁，立即返回假。它不会自旋等待lock被释放。
|
CODE:spin_lock(lock) |
该宏用于获得自旋锁lock，如果能够立即获得锁，它就马上返回，否则，它将自旋在那里，直到该自旋锁的保持者释放，这时，它获得锁并返回。总之，只有它获得锁才返回。
|
CODE:spin_lock_irqsave(lock, flags) |
该宏获得自旋锁的同时把标志寄存器的值保存到变量flags中并失效本地中断。
|
CODE:spin_lock_irq(lock) |
该宏类似于spin_lock_irqsave，只是该宏不保存标志寄存器的值。禁止本地中断并获取指定的锁
|
CODE:spin_lock_bh(lock) |
该宏在得到自旋锁的同时失效本地软中断。
|
CODE:spin_unlock(lock) |
该宏释放自旋锁lock，它与spin_trylock或spin_lock配对使用。如果spin_trylock返回假，表明没有获得自旋锁，因此不必使用spin_unlock释放。
|
CODE:spin_unlock_irqrestore(lock, flags) |
该宏释放自旋锁lock的同时，也恢复标志寄存器的值为变量flags保存的值。它与spin_lock_irqsave配对使用。
|
CODE:spin_unlock_irq(lock) |
该宏释放自旋锁lock的同时，并激活本地中断。它与spin_lock_irq配对应用。
|
CODE:spin_unlock_bh(lock) |
该宏释放自旋锁lock的同时，也使能本地的软中断。它与spin_lock_bh配对使用。
|
CODE:spin_trylock_irqsave(lock, flags) |
该宏如果获得自旋锁lock，它也将保存标志寄存器的值到变量flags中，并且失效本地中断，如果没有获得锁，它什么也不做。
因此如果能够立即获得锁，它等同于spin_lock_irqsave，如果不能获得锁，它等同于spin_trylock。如果该宏获得自旋锁lock，那需要使用spin_unlock_irqrestore来释放。
|
CODE:spin_trylock_irq(lock) |
该宏类似于spin_trylock_irqsave，只是该宏不保存标志寄存器。如果该宏获得自旋锁lock，需要使用spin_unlock_irq来释放。
|
CODE:spin_trylock_bh(lock) |
该宏如果获得了自旋锁，它也将失效本地软中断。如果得不到锁，它什么也不做。因此，如果得到了锁，它等同于spin_lock_bh，如果得不到锁，它等同于spin_trylock。如果该宏得到了自旋锁，需要使用spin_unlock_bh来释放。
|
CODE:spin_can_lock(lock) |
该宏用于判断自旋锁lock是否能够被锁，它实际是spin_is_locked取反。如果lock没有被锁，它返回真，否则，返回假。该宏在2.6.11中第一次被定义，在先前的内核中并没有该宏。
自旋锁的基本使用如下：
|
CODE:spinlock_t myr_lock = SPIN_LOCK_UNLOCKED;
spin_lock(&myr_lock);
/*临界区*/
spin_unlock(&myr_lock); |
因为自旋锁在同一时刻至多被一个执行线程持有，所以一个时刻只能有一个线程位于临界区，这就 为多处理器提供了防止并发访问所需的保护机制，但是在单处理器上，编译的时候不会加入自旋锁。它仅仅被当作一个设置内核抢占机制是否被启用的开关。注意， Linux内核实现的自旋锁是不可递归的，这一点不同于自旋锁在其他操作系统中的实现，如果你想得到一个你正持有的锁，你必须自旋，等待你自己释放这个 锁，但是你处于自旋忙等待中，所以永远没有机会释放锁，于是你就被自己锁死了，一定要注意！
自旋锁可以用在中断处理程序中，但是在使用时一定要在获取锁之前，首先禁止本地 中断（当前处理器上的中断），否则中断处理程序就可能打断正持有锁的内核代码，有可能会试图支争用这个已经被持有的自旋锁。这样一来，中断处理程序就会自 旋，等待该锁重新可用，但是锁的持有者在这个中断处理程序执行完毕之前不可能运行，这就会造成双重请求死锁。
自旋锁与下半部：由于下半部（中断程序下半部）可以抢占进程上下文中的代码，所 以当下半部和进程上下文共享数据时，必须对进程上下文中的共享数据进行保护，所以需要加锁的同时还要禁止下半部执行。同样，由于中断处理程序可以抢占下半 部，所以如果中断处理程序和下半部共享数据，那么就必须在获取恰当的锁的同时还要禁止中断。对于软中断，无论是否同种类型，如果数据被软中断共享，那么它 必须得到锁的保护，因为同种类型的两个软中断也可以同进运行在一个系统的多个处理器上。但是，同一个处理器上的一个软中断绝不会抢占另一个软中断，因此， 根本不需要禁止下半部。
