【linux kernel 入门及渐进 2 -- linux 内核同步机制之spinlock】

主公讲 ARM

已于 2022-12-09 16:28:41 修改

阅读量568

点赞数

分类专栏： ARM BSP 系列文章标签： linux arm

于 2022-12-09 15:57:23 首次发布

主公讲ARM

本文链接：https://blog.youkuaiyun.com/sinat_32960911/article/details/128252371

版权

ARM BSP 系列专栏收录该内容

13 篇文章

订阅专栏

文章目录

- 1.1 spinlock 种类

1.1 spinlock 种类

1.1.1 spin_lock

很多时候我们并不能采用其他的锁，比如读写锁、互斥锁、信号量等。一方面这些锁会发生上下文切换，他的时间是不可预期的，对于一些简单的、极短的临界区完全是一种性能损耗；另一方面在中断上下文是不允许睡眠的，除了自旋锁以外的其他任何形式的锁都有可能导致睡眠或者进程切换，这是违背了中断的设计初衷，会发生不可预知的错误。基于两点，我们需要自旋锁，他是不可替代的。

1.1.2 spin_lock_irq

如果被保护的共享资源在软中断（包括 tasklet 和 timer）或进程上下文和硬中断上下文访问，那么在软中断或进程上下文访问期间，可能被硬中断打断，从而进入硬中断上下文对共享资源进行访问，因此，在进程或软中断上下文需要使用spin_lock_irq 和 spin_unlock_irq 来保护对共享资源的访问。

当然，由于需要关闭中断，会导致系统的响应降低，而且还会执行更多的代码，可能会导致性能下降。

1.1.3 spin_lock_irqsave

当进程在执行第一个 spin_lock_irq(&lock1) 时已经关闭了中断，然后继续获取第二个自旋锁 spin_lock_irq(&lock2)，当 lock2 解锁后且 lock1 未解锁前这一段区域处于一种硬件中断开启的状态，这段代码仍然处于 lock1 的临界区，如果此时硬件中断也需要申请 lock1 锁会导致死锁，这是因为 spin_unlock_irq 在解锁时一定会将本地 CPU 的中断打开，从而导致硬件中断可以重新强制抢占 CPU，所以最好的方式就是 lock2 在锁之前保存当前的中断状态，在解锁时恢复当前的中断状态，这也就是 spin_lock_irqsave 需要存在的原因。自然地，这是一种更为线程安全的方案，但是他会带来比前面几种更加多的性能损耗。

在使用 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 最好。

1.1.4 spin_lock_bh

spin_lock_bh() 主要用于保护其他进程上下文访问软中断函数共享的变量, 因为spin_lock() 无法禁止软中断执行。

共享资源只在进程上下文访问和软中断上下文访问，那么当在进程上下文访问共享资源时，可能被软中断打断，从而可能进入软中断上下文来对被保护的共享资源访问，因此对于这种情况，对共享资源的访问必须使用 spin_lock_bh 和spin_unlock_bh 来保护。

当然使用 spin_lock_irq 和 spin_unlock_irq 以及 spin_lock_irqsave 和spin_unlock_irqrestore 也可以，它们失效了本地硬中断，失效硬中断隐式地也失效了软中断。但是使用 spin_lock_bh 和 spin_unlock_bh 是最恰当的，它比其他两个快。

如果被保护的共享资源只在进程上下文和 tasklet 或 timer 上下文访问，那么应该使用与上面情况相同的获得和释放锁的宏，因为 tasklet 和 timer 是用软中断实现的。

1.1.5 单 tasklet 和 timer场景

如果被保护的共享资源只在一个 tasklet 或 timer 上下文访问，那么不需要任何自旋锁保护，因为同一个 tasklet 或 timer 只能在一个 CPU 上运行，即使是在 SMP环境下也是如此。实际上 tasklet 在调用 tasklet_schedule 标记其需要被调度时已经把该 tasklet 绑定到当前 CPU，因此同一个 tasklet 决不可能同时在其他 CPU上运行。

timer 也是在其被使用 add_timer 添加到 timer 队列中时已经被帮定到当前CPU，所以同一个 timer 绝不可能运行在其他 CPU 上。当然同一个 tasklet 有两个实例同时运行在同一个CPU就更不可能了。

1.1.6 多 tasklet 和 timer 场景

如果被保护的共享资源只在两个或多个 tasklet 或 timer 上下文访问，那么对共享资源的访问仅需要用 spin_lock 和 spin_unlock 来保护，不必使用 _bh 版本，因为当 tasklet 或 timer 运行时，不可能有其他 tasklet 或 timer 在当前CPU上运行。