自旋锁的应用

直奔主题，不介绍自旋锁是如何如何。。

 

自旋锁的应用

在讨论自旋锁的应用时，

单且非

多||抢内

我们一般区分两种平台：单处理器且非抢占式内核和对称多处理器或抢占式内核。

在前面我们看到，在单处理器非抢占式内核下，自旋锁根本不存在。这体现了一种出色的设计策略，既然没有别人能够同时刻执行，就没有理由加锁。对于抢占式内核，我们将它等同于对称多处理器来考虑。
1． 用户上下文之间
如果数据结构只可能被用户上下文访问，最高效的办法就是使用信号量。（我们在后面将讨论信号量机制）。
2． 用户上下文与softirq之间
这种情况下，使用spin_lock_bh()/spin_unlock_bh()可以满足要求。如果是单处理器非抢占式内核，自旋锁消失了，spin_lock_bh等同于local_bh_disable，会禁止在用户上下文时进制softirq，从而避免用户上下文和softirq同时进入临界区。如果是对称多处理器或者抢占式内核，即使是在不同CPU上的用户上下文和softirq同时运行，自旋锁机制保证了只有一个持有者，只有在它释放锁之后，另一个才能进入临界区。
3． 用户上下文和Tasklet/Timer之间
同上。同加锁观点来看，Tasklet和Timer的地位是同样的。
4． Tasklet或Timer之间
这里有两点需要说明：（1）同一时刻，一个Tasklet或Timer不会同时在两个CPU上执行；（2）如果CPU已经处在Tasklet或Timer 中，它不会同时再执行其它的Tasklet或Timer。因此我们只需要考虑在不同CPU上运行两个不同Tasklet或Timer的情况，而这种情况只需要使用自旋锁机制，即spin_lock和spin_unlock函数。
5． Softirq之间或和Tasklet/Timer之间
同一个softirq可能在不同的CPU上执行，同上道理，使用spin_lock和spin_unlock可以在不同CPU的同一个或不同softirq，或者Softirq与Tasklet或Timer之间保护共享数据。
6． 硬件中断之间
如果被保护的共享资源在软中断（包括tasklet和timer）或进程上下文和硬中断上下文访问，那么在软中断或进程上下文访问期间，可能被硬中断打断，从而进入硬中断上下文对共享资源进行访问，因此，在进程或软中断上下文需要使用spin_lock_irq和spin_unlock_irq来保护对共享资源的访问。
而在中断处理句柄中使用什么版本，需依情况而定，如果只有一个中断处理句柄访问该共享资源，那么在中断处理句柄中仅需要spin_lock和spin_unlock来保护对共享资源的访问就可以了。
因为在执行中断处理句柄期间，不可能被同一CPU上的软中断或进程打断。但是如果有不同的中断处理句柄访问该共享资源，那么需要在中断处理句柄中使用spin_lock_irq和spin_unlock_irq来保护对共享资源的访问。
在使用spin_lock_irq和spin_unlock_irq的情况下，完全可以用spin_lock_irqsave和 spin_unlock_irqrestore取代，具体应该使用哪一个也需要依情况而定，如果可以确信在对共享资源访问前中断是打开的，那么使用 spin_lock_irq更好一些，因为它比spin_lock_irqsave要快一些。
但是如果不能确定是否中断使能，那么使用spin_lock_irqsave和spin_unlock_irqrestore更好，因为它将恢复访问共享资源前的中断标志而不是直接打开中断。 当然，有些情况下需要在访问共享资源时必须禁止中断，而访问完后必须打开中断，这样的情形使用spin_lock_irq和 spin_unlock_irq最好。

spin_lock_irq和spin_lock_irqsave的区别， 之前 中断是否是打开的。 不能确定则用后者，保存-恢复。

总结起来，一句话，自旋锁很多种。

 获取自旋锁前要禁止中断，你不获取锁不需要禁止中断啊。自旋锁过程中是一直禁止中断的呀。

 

转自：

http://blog.chinaunix.net/uid-20184656-id-138057.html