linux内核互斥问题总结#1

自己看书的一点点总结，先不管对不对，乱笔头而已。

linux中的同步涉及到两个问题：当前是否允许中断，当前是否允许调度。既允许中断，又允许调度状态下的同步，不在此文讨论之内。

为了方便描述，CPU当前指令状态分为下面几种：
1. IRQ-handler状态下，此时正在运行注册的中断处理函数。
2. tasklet/soft-irq状态下，也就是一般的下半部。
3. 一般任务状态下。此时current有效，处理器在运行某个进程。
2和3合称为非IRQ-Handler态。

linux中不允许（不会）的中断产生的地方：
1. 中断处理程序中，注册中断处理程序如果指定了SA_INTERRUPT标志，则说明在中断处理中，不允许打开中断。x86的CPU跳转到中断向量处时，当前CPU的中断会关闭。一般中断处理程序运行时，中断会打开，可以减少中断延时。也就是说，中断处理程序运行的时候，一般情况下，是可能被其它中断抢占的（有些CPU会有一些中断优先级的概念），除非你的中断程序要求此间要关闭中断运行。
2. 另外一个时间就是程序中通过local_irq_save关闭当前处理器的中断。

IRQ-handler的同步考虑
1. 针对某一IRQ的运行，在do_IRQ中会先spinlock住当前的irq number。所以不需要考虑相同的中断重入的问题，即使是SMP的情况下也不用考虑。
2. 程序中可以调用disable_irq(irq)/enable_irq(irq)之类的函数，控制PIC上是否产生中断。一般情况下，应该会比较少用到这样的代码。非常少见的情况是多个中断共享的资源的同步，也仅仅标志成SA_INTERRUPT，这样就可以在当前CPU关闭中断的情况下运行，当然，spinlock还是少不了的。

IRQ-handler，也就是我们的中断处理程序时，如果需要访问临界资源，如果此资源是与非irq-handler竞争, 一般都应该是使用spinlock。而与之对应的非IRQ-hander中的访问相同的临界资源，则需要既锁中断，又要拿住spinlock。

soft irq/tasklet的同步考虑
1. soft irq运行时，中断是开户的，并且同一softirq会在多个CPU上运行。所以一般的策略是softirq应该尽量减少资源的共享，使用per-cpu的变量。
2. tasklet具有自身的互斥性，即同一时间同中tasklet只会在一个CPU上运行。

softirq/tasklet都属于in_interrupt环境，即非进程状态，理论上不应该访问current。如果需要与中断进行互斥，一般应该如前述：锁中断并加spinlock锁。

其它，如seq锁，RCU锁也可以依此分析。往简单里分析：中断irq_handler中，通过spinlock拿资源。atomic环境下，锁中断，拿spinlock。