中断机制的引入

在前面的文章中，我们理解到为了让灵活的软件来控制计算机，我们有了很多精巧的设计。cpu可以解析执行一些列指令，指令的组合组成程序。程序装入内存中，由cpu 自动一条一条的解析执行，而且巧妙的实现了指令的跳转。同时，巧妙的引入了设备控制器（设备适配器）来控制设备，cpu与设备控制器之间通过桥和总线连接在一起，通过总线协议进行交互。cpu通过与设备管理器的交互实现对设备的读写和控制。这样看起来已很完美，在这种机制下，我们可以写出千变万化的软件来使用我们的硬件功能。但是，这里面还隐藏着一些问题。

为什么需要中断机制
如果我们的软件执行过程中，不用与外部交互，程序永远按部就班执行，不需要干预，不需要人机交互，那确实有前面的机制就够了。但是我们在使用过程中发现，我们的需求不止这些。如我们开机之后，有时想上网，有时像听歌，有时写写博客，这种想法是随机的突发的，程序不可能预先知道。针对这样的需求，我们必须提供人机交互手段。比如在软件执行过程中有人动态的通知软件现在需要帮我干什么活。

人机交互如何实现呢，经典配置是键盘和鼠标等输入设备的引入和显示器等输出设备的引入。也许有人会问，引入这类设备的设备管理器io控制，cpu不就可以控制他们了吗，有什么不一样的吗？还真有点不同。以前的那种方式适合于随时都可以对设备进行读写，而对于键盘和鼠标，只能读，而且并不是每次读都有值，只有在人偶尔兴起的时候“写”入了值，才有的读。当然，我们可以隔一段时间就去读一次，这样确实能起到效果，但是效率是不是有点低呢？

所以，对于这类设备的控制，我们引入了中断控制的思想。设备的接口上有一条线是中断请求线。当键盘点击事件发生后，硬件会自动触发中断请求信号。这个请求信号会通到cpu, cpu在执行完每一条指令后，会“感应”下中断请求信号，如果有，就会触发中断处理流程。大致是这样的，首先对当前运行环境进行保存，然后由硬件机制获取是谁申请的中断，获取中断号，根据中断号找到对应的中断处理程序即软件部分，然后将执行权交给中断处理程序去执行。执行完后恢复以前的运行环境。

键盘中断为例
以键盘使用为例，我们可以这样进行控制。首先系统应该准备有键盘中断处理程序，每当按键事件触发后，键盘中断处理程序会将按键事件存入到内存缓冲区中。同时在程序中，需要获取按键信息时，则查询那个缓冲区，看有没有按键信息，不断轮询，直到有按键信息。我们发现这里也是要轮询的，而且还多了个中断处理流程，有意义吗？当然有。以前轮询的是设备控制器的io空间，每次查询需要占用总线，消耗资源多而且慢，现在轮询的是内存空间，速度快且不占用io总线，减轻了系统的负担。

通过这篇文章，我们应该对中断机制有一个初步的了解，至于软件部分如何利用硬件中断机制来为应用程序服务，那就属于软件架构考虑的范畴了。同时我们可以感受一下计算机设计之美