关于中断的一点点认识

前一段时间，有幸和都江堰操作的作者面对面的聊了一把。对于前辈的技术和才能，晚辈深深地佩服。DJY_OS在应用方面的事件机制以及处理中断的方法都让人眼前一亮。在谈到中断时，前辈说，很多人都没有真正的理解中断。于是我就请教了前辈。他说：
“http://www.djyos.com/bbs/forum.php?mod=viewthread&tid=6082&extra=page%3D1
1、  中断是异步事件。
2、  中断不一定是紧急事件。
3、  紧急事件必须用中断来通知。
关键是这三句话。”
 
其实，我听了以后，还是有点迷糊。第一什么是异步事件？Google一下，异步事件是指计算机外部产生的,同计算机内执行的任务在时间上不相关联的事件。(http://define.cnki.net/WebForms/WebDefines.aspx?searchword=%E5%BC%82%E6%AD%A5%E4%BA%8B%E4%BB%B6)

那么这里有个疑问了，软中断是由软件出发的，一般用于呼叫系统服务。这时应用程序必须等待系统服务完成后才能从软中断处继续执行。显然，这种事件不满足这个异步事件的定义，那么它还算是中断吗？也许前辈只是借用了异步事件的术语，指得其它的东西。疑惑促使我去思考这些问题。

中断系统一直困扰着我。我不明白中断和任务最本质的区别。这里先提一下调度，调度的本质是分配CPU的时间。即分配CPU的计算时间给每一个需要计算的任务(线程)。中断发生以后，需要执行中断服务程序(ISR)。ISR显然也有一些任务(线程)的影子。

有一些新CPU，如Cortex-M3之类的，有NVIC，中断控制器。不需要软件做栈的保护(它自己可以做)，上电以后初始化栈后，它自己就可以正常工作了。支持背靠背执行ISR。其他处理器上的系统都是执行完了ISR后，再执行一条非ISR指令，防止频繁执行ISR造成前台程序饿死。背靠背的意思是ISR执行完毕后，直接执行另外一个ISR，不执行任何前台代码。这有个好处，没有用户程序的压栈出栈，现场保护。速度快了很多。缺点就是，如果中断很多的话，前台程序得不到执行(不过这个效应应该不明显)。

所有这些，让我想到，中断控制器实际上不就是个带优先级别支持抢占的硬件调度器吗？:)，事实的确如此。一个高优先级的ISR不退出的话，低优先级的ISR是得不到服务的。低优先级的ISR在服务时，发生高优先级的ISR，那么直接就被抢占了。我们用关闭中断，实际上就是关闭硬件的调度器。而操作系统(OS)，从这个硬件调度器来看，实际上相当于空闲任务(或进程)。当系统没有ISR运行的时候，自然运行空闲任务，也就是操作系统的(OS)。这么一看，这是多么的与抢占式的软件调度器吻合。

硬件只提供了一个抢占式的调度器，并未在此基础上提供丰富的系统调用，诸如信号量、互斥体等等API。而软件调度器是我们真正想要的东西。软件提供了各种各样的同步、通信API。用以管理系统内部的资源。一山容不得二虎，必须有一个主一个从。软件调度器作为我们需要的主流，硬件调度器自然退为二线，默默支持着主调度器。

从硬件调度器的角度去观察，衍生出很多有力的解释：
1.既然硬件调度器被抑制，那么要以主调度器为主。中断ISR应尽可能做最少的事情。尽量不影响主调度器的工作。
2.硬件调度器是个基于优先级的抢占内核，而OS运行在最低优先级。在ISR里不能调用阻塞的函数。调用了，整个系统就崩溃了。或者说发生了优先级反转，但硬件调度器没有提供这个功能。只能是死锁或者是长时间的等待。
3.硬件调度器使用的栈(包括ISR)应该是和操作系统在一个数据空间里。因为硬件调度器高于软件调度器，即软件调度器只能是停止硬件调度器调度，但无法介入这一调度过程。硬件调度器可没有提供诸如MMU切换之类的功能。
4.对于资源的拥有性上来说，操作系统(软件调度器)接管了所有的资源，甚至它把中断也当成了一种资源。对于硬件调度器，它只能拥有最基本的可以使程序运行的资源。即一点点内存+CPU的时间。内存是软件调度器与之分享的，由操作系统全权接管。
...

一点点拙见，大家拍砖。

-----------------------------------------------------------------------

DJYOS作者，罗大哥的指教：

罗大哥  20:38:16
看了，兄弟有独到的见解，但有些观点还是可以商榷的。
Ultra-Apple  20:39:42
指教。
罗大哥  20:39:56
比如软中断，这里的“中断”，指的是swi指令（x86的int指令）的响应过程，有点像中断。
1、会陷入特权级。
2、多数会有独立的栈。
至于背靠背，不仅仅m3，ARMx都是背靠背的。
Ultra-Apple  20:42:03
:)
罗大哥  20:42:47
所以，现在“软中断”这个术语，很多著作上倾向于用“异常”这个术语替代。
Ultra-Apple  20:46:12
:)
罗大哥  20:46:42
另外，吧中断上升到硬调度器的高度，感觉有点牵强
Ultra-Apple  20:48:21
哦
罗大哥  20:49:39
当然，从处理过程上，也确实像调度器。
Ultra-Apple  20:50:55
恩，写得不好，让罗大哥见笑了。
本来想表达的意思是用ARM举例，不仅限于ARM。

--------------------------------------------------------------------------------------文章补遗---------------------------------------------------------------------

又和罗大哥讨论了一下，水平有限，文中的确有一些模棱两可的地方。补充一下，完善本文的观点。
底层程序员观察来看：
1.中断是异步事件；什么时候发生的确依赖于客观世界，无法控制。
2.软中断是软件控制的，是同步事件；大多数文献倾向软中断为异常。
3.除数为0，译码错误，地址错误等等异常，也可看作中断，它们是一类特殊的异常。
4.异常和中断最大的区别是，产生的源不同；服务的对象不同。

从CPU来看：
1.中断是异步事件；
2.软中断也是异步事件， CPU不知道代码什么时候想软中断；
3.其他类的异常也是异步事件。
假设如果用FPGA实现CPU的话，用异步的方式可以统一这些设计。换句话说，虽然概念上区分异常和中断，但在内在实现上是高度相似的。

继续从CPU来看：
1.不可屏蔽中断，是最高优先级中断且不受中断禁止的制约；
2.普通的中断可以配置优先级别；
3.异常分为两类，一类是可屏蔽的；一类是不可屏蔽的。不可屏蔽的异常优先级和不可屏蔽中断有得一拼(应该是有优先级差别的)；可屏蔽异常的优先级应该比普通中断低。
4.在以上服务程序都没有工作的时候，运行操作系统。

抽象一下，如果把CPU看成一个类似RTEMS、uCOS-II之类的RTOS的话。实际上ISR也好，异常服务也好，操作系统也好，都是“硬件调度器”的任务。而操作系统是硬件调度器的空闲任务。