linux设备驱动：中断下半部的三种实现机制

1. 软中断

   软中断是一组静态定义的下半部接口，有 32 个，可以在所有处理器上同时执行，类型相同，也可以在编译时静态注册。
   

asmlinkage void do_softirq(void)
{
    __u32 pending;
    unsigned long flags;

    /* 判断是否在中断处理中，如果正在中断处理，就直接返回 */
    if (in_interrupt())
        return;

    /* 保存当前寄存器的值 */
    local_irq_save(flags);

    /* 取得当前已注册软中断的位图 */
    pending = local_softirq_pending();

    /* 循环处理所有已注册的软中断 */
    if (pending)
        __do_softirq();

    /* 恢复寄存器的值到中断处理前 */
    local_irq_restore(flags);
}

代码之中第一次就判断是否在中断处理中，如果在立刻退出函数。这说明了什么?说明了如果有其他软中断触发，执行到此处由于先前的软中断已经在处理，则其他软中断会返回。所以，软中断不能被另外一个软中断抢占!唯一可以抢占软中断的是中断处理程序，所以软中断允许响应中断。虽然不能在本处理器上抢占，但是其他的软中断甚至同类型可以在其他处理器上同时执行。由于这点，所以对临界区需要加锁保护。

软中断留给对时间要求最严格的下半部使用。目前只有网络，内核定时器和 tasklet 建立在软中断上。

---

2. Tasklet

   基于软中断实现的，灵活性强，动态创建的下半部实现机制。两个不同类型的 tasklet 可以在不同处理器上运行，但相同的不可以，可以通过代码动态注册。

   在 SMP 上，调用 tasklet 是会检测 TASKLET_STATE_SCHED 标志，如果同类型在运行，就退出函数。

   tasklet 由于是基于软中断实现的，所以也允许响应中断。但不能睡眠(我认为不能睡眠原因是它们内部有 spin lock)。

3. 工作队列

   工作队列（work queue）是另外一种将中断的部分工作推后的一种方式，它可以实现一些tasklet不能实现的工作，比如工作队列机制可以睡眠。这种差异的本质原因是，在工作队列机制中，将推后的工作交给一个称之为工作者线程（worker thread）的内核线程去完成（单核下一般会交给默认的线程events/0）。因此，在该机制中，当内核在执行中断的剩余工作时就处在进程上下文（process context）中。也就是说由工作队列所执行的中断代码会表现出进程的一些特性，最典型的就是可以重新调度甚至睡眠。

   对于tasklet机制（中断处理程序也是如此），内核在执行时处于中断上下文（interrupt context）中。而中断上下文与进程毫无瓜葛，所以在中断上下文中就不能睡眠。因此，选择tasklet还是工作队列来完成下半部分应该不难选择。当推后的那部分中断程序需要睡眠时，工作队列毫无疑问是你的最佳选择；否则，还是用tasklet吧。

---

4.1 相关概念理解：中断上下文与进程上下文

在了解中断上下文时，先来回顾另一个熟悉概念：进程上下文（这个中文翻译真的不是很好理解，用“环境”比它好很多）。一般的进程运行在用户态，如果这个进程进行了系统调用，那么此时用户空间中的程序就进入了内核空间，并且称内核代表该进程运行于内核空间中。由于用户空间和内核空间具有不同的地址映射，并且用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行。这样就产生了进程上下文。

所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈中的内容。当内核需要切换到另一个进程时（上下文切换），它需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态继续执行。上述所说的工作队列所要做的工作都交给工作者线程来处理，因此它可以表现出进程的一些特性，比如说可以睡眠等。

对于中断而言，是硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境，主要是被中断的进程的环境。因此处于中断上下文的tasklet不会有睡眠这样的特性。

4.2 相关概念理解：中断中为何不能使用信号量？中断上下为何不能睡眠？

信号量会导致睡眠

中断发生以后，CPU跳到内核设置好的中断处理代码中去，由这部分内核代码来处理中断。这个处理过程中的上下文就是中断上下文。

为什么可能导致睡眠的函数都不能在中断上下文中使用呢？ 首先睡眠的含义是将进程置于“睡眠”状态，在这个状态的进程不能被调度执行。然后，在一定的时机，这个进程可能会被重新置为“运行”状态，从而可能被调度执行。 可见，“睡眠”与“运行”是针对进程而言的，代表进程的task_struct结构记录着进程的状态。内核中的“调度器”通过task_struct对进程进行调度。

但是，中断上下文却不是一个进程，它并不存在task_struct，所以它是不可调度的。所以，在中断上下文就不能睡眠。

那么，中断上下文为什么不存在对应的task_struct结构呢？

中断的产生是很频繁的（至少每毫秒（看配置，可能10毫秒或其他值）会产生一个时钟中断），并且中断处理过程会很快。如果为中断上下文维护一个对应的task_struct结构，那么这个结构频繁地分配、回收、并且影响调度器的管理，这样会对整个系统的吞吐量有所影响。

但是在某些追求实时性的嵌入式linux中，中断也可能被赋予task_struct结构。这是为了避免大量中断不断的嵌套，导致一段时间内CPU总是运行在中断上下文，使得某些优先级非常高的进程得不到运行。这种做法能够提高系统的实时性，但是代价中吞吐量的降低