了解Linux中断处理原理_技术

Linux中断下半部处理有三种方式：软中断、tasklet、工作队列。

曾经有人问我为什么要分这几种，该怎么用。当时用书上的东西蒙混了过去，但是自己明白自己实际上是不懂的。最近有时间了，于是试着整理一下linux的中断处理机制，目的是起码从原理上能够说得通。

一、最简单的中断机制

最简单的中断机制就是像芯片手册上讲的那样，在中断向量表中填入跳转到对应处理函数的指令，然后在处理函数中实现需要的功能。类似下图：

这种方式在原来的单片机课程中常常用到，一些简单的单片机系统也是这样用。

它的好处很明显，简单，直接。

二、下半部

中断处理函数所作的第一件事情是什么？答案是屏蔽中断（或者是什么都不做，因为常常是如果不清除IF位，就等于屏蔽中断了），当然只屏蔽同一种中断。之所以要屏蔽中断，是因为新的中断会再次调用中断处理函数，导致原来中断处理现场的破坏。即，破坏了 interrupt context。

随着系统的不断复杂，中断处理函数要做的事情也越来越多，多到都来不及接收新的中断了。于是发生了中断丢失，这显然不行，于是产生了新的机制：分离中断接收与中断处理过程。中断接收在屏蔽中断的情况下完成；中断处理在时能中断的情况下完成，这部分被称为中断下半部。

从上图中看，只看int0的处理。Func0为中断接收函数。中断只能简单的触发func0，而func0则能做更多的事情，它与funcA之间可以使用队列等缓存机制。当又有中断发生时，func0被触发，然后发送一个中断请求到缓存队列，然后让funcA去处理。

由于func0做的事情是很简单的，所以不会影响int0的再次接收。而且在func0返回时就会使能int0，因此funcA执行时间再长也不会影响int0的接收。

三、软中断

下面看看linux中断处理。作为一个 *** 作系统显然不能任由每个中断都各自为政，统一管理是必须的。

我们不可中断部分的共同部分放在函数do_IRQ中，需要添加中断处理函数时，通过request_irq实现。下半部放在do_sofTIrq中，也就是软中断，通过open_sofTIrq添加对应的处理函数。

四、tasklet

旧事物跟不上历史的发展时，总会有新事物出现。

随着中断数的不停增加，软中断不够用了，于是下半部又做了进化。

软中断用轮询的方式处理。假如正好是最后一种中断，则必须循环完所有的中断类型，才能最终执行对应的处理函数。显然当年开发人员为了保证轮询的效率，于是限制中断个数为32个。

为了提高中断处理数量，顺道改进处理效率，于是产生了tasklet机制。

Tasklet采用无差别的队列机制，有中断时才执行，免去了循环查表之苦。

总结下tasklet的优点：

（1）无类型数量限制；

（2）效率高，无需循环查表；

（3）支持SMP机制；

五、工作队列

前面的机制不论如何折腾，有一点是不会变的。它们都在中断上下文中。什么意思？说明它们不可挂起。而且由于是串行执行，因此只要有一个处理时间较长，则会导致其他中断响应的延迟。为了完成这些不可能完成的任务，于是出现了工作队列。工作队列说白了就是一组内核线程，作为中断守护线程来使用。多个中断可以放在一个线程中，也可以每个中断分配一个线程。

工作队列对线程作了封装，使用起来更方便。

因为工作队列是线程，所以我们可以使用所有可以在线程中使用的方法。