操作系统和中断

硬中断和软中断

硬中断由与系统相连的外设(比如网卡、硬盘)自动产生的。主要是用来通知操作系统系统外设状态的变化。比如当网卡收到数据包的时候，就会发出一个中断。我们通常所说的中断指的是硬中断(hardirq)。硬中断是可以屏蔽的，软中断是不可以屏蔽的。

软中断则是手动由中断指令产生。内核不会立即处理重新触发的软中断。当大量软中断出现的时候，内核会唤醒一组内核线程来处理。这些线程的优先级最低(nice值为19)，这能避免它们跟其它重要的任务抢夺资源。但它们最终肯定会被执行，所以这个折中的方案能够保证在软中断很多时用户程序不会因为得不到处理时间而处于饥饿状态，同时也保证过量的软中断最终会得到处理。

设计中断系统时，硬中断用于紧急的响应，而软中断一般用于处理硬中断没有完成的工作。

中断有两个重要的属性，中断号和中断处理程序。中断号用来标识不同的中断，不同的中断具有不同的中断处理程序。在操作系统内核中维护着一个中断向量表（Interrupt Vector Table），这个数组存储了所有中断处理程序的地址，而中断号就是相应中断在中断向量表中的偏移量。

中断与驱动

1. 中断产生时候 保护系统当前状态，也就是把cpu当前的状态保存起来

2. 执行中断程序，执行的中断程序应该尽量短，不去过多占用cpu时长，此处引入Linux的頂半部机制以及底半部机制，頂半部是指中断代码需要立即执行的情况，对于情况不紧急的情况，会将中断程序注册到队列，在cpu运行状态不是那么繁忙的情况下再去执行程序，底半部机制是指中带代码需要立即执行，不得延误（后面会详细介绍頂半部机制以及底半部机制）。

3. 恢复现场工作，中断执行后，跳出中断程序，并恢复中断前cpu状态，继续执行之前的任务

Linux实现下半部的机制主要有tasklet和工作队列。

tasklet或者软中断

记住tasklet是一个可以在由系统决定的安全时刻在软件中断上下文被调度运行的特殊函数，它们可以被多次调度运行，但tasklet不会积累，也就是说，实际只会运行一次。不会有同一个tasklet的多个实例并行的运行，因为它们只运行一次，但是tasklet可以与其它的tasklet并行的运行在对称多处理器（SMP)系统上。如果驱动程序中有多个tasklet,它们必须使用某种机制锁来避免冲突。tasklet在中断处理例程结束前不会开始运行，tasklet运行时，可以有其它的中断发生。tasklet通常是底半部处理的优选机制，因为这种机制非常快，但是所有的tasklet都必须是原子的。

tasklet就是软中断实现的。。当然也可以通过直接修改内核自己加入自己的软中断，但是一般来说这是不合理的，软中断的优先级比较高，如果不是在内核处理频繁的任务不建议使用。通常驱动用户使用 tasklet 足够了。

工作队列

从上面的介绍看以看出，软中断运行在中断上下文中，因此不能阻塞和睡眠，而tasklet使用软中断实现，当然也不能阻塞和睡眠。但如果某延迟处理函数需要睡眠或者阻塞呢？没关系工作队列就可以如您所愿了。
把推后执行的任务叫做工作（work），描述它的数据结构为work_struct ，这些工作以队列结构组织成工作队列（workqueue），其数据结构为workqueue_struct ，而工作线程就是负责执行工作队列中的工作。系统默认的工作者线程为events。
工作队列(work queue)是另外一种将工作推后执行的形式。工作队列可以把工作推后，交由一个内核线程去执行—这个下半部分总是会在进程上下文执行，但由于是内核线程，其不能访问用户空间。最重要特点的就是工作队列允许重新调度甚至是睡眠。
通常，在工作队列和软中断/tasklet中作出选择非常容易。可使用以下规则：

• 如果推后执行的任务需要睡眠，那么只能选择工作队列。
• 如果推后执行的任务需要延时指定的时间再触发，那么使用工作队列，因为其可以利用timer延时(内核定时器实现)。
• 如果推后执行的任务需要在一个tick之内处理，则使用软中断或tasklet，因为其可以抢占普通进程和内核线程，同时不可睡眠。
• 如果推后执行的任务对延迟的时间没有任何要求，则使用工作队列，此时通常为无关紧要的任务。
  实际上，工作队列的本质就是将工作交给内核线程处理，因此其可以用内核线程替换。但是内核线程的创建和销毁对编程者的要求较高，而工作队列实现了内核线程的封装，不易出错，所以我们也推荐使用工作队列。