本文通过日常生活场景类比，详细解释了计算机中断机制的概念及其在提高并发处理能力中的作用。利用模拟中断的程序示例，展示了如何通过异步事件处理机制实现任务的并行执行，从而有效提升系统的效率。
这部分内容来自http://www.kerneltravel.net/内核之旅的电子杂志第八期《中断》，再次提起，是希望你知道，那个困扰我们的中断原来不过如此。
一、中断是什么
中断的汉语解释是半中间发生阻隔、停顿或故障而断开。那么，在计算机系统中，我们为什么需要“阻隔、停顿和断开”呢？
举个日常生活中的例子，比如说我正在厨房用煤气烧一壶水，这样就只能守在厨房里，苦苦等着水开——如果水溢出来浇灭了煤气，有可能就要发生一场灾难了。等啊等啊，外边突然传来了惊奇的叫声“怎么不关水龙头？”于是我惭愧的发现，刚才接水之后只顾着抱怨这份无聊的差事，居然忘了这事，于是慌慌张张的冲向水管，三下两下关了龙头，声音又传到耳边，“怎么干什么都是这么马虎？”。伸伸舌头，这件小事就这么过去了，我落寞的眼神又落在了水壶上。
门外忽然又传来了铿锵有力的歌声，我最喜欢的古装剧要开演了，真想夺门而出，然而，听着水壶发出“咕嘟咕嘟”的声音，我清楚：除非等到水开，否则没有我享受人生的时候。
这个场景跟中断有什么关系呢？
如果说我专心致志等待水开是一个过程的话，那么叫声、电视里传出的音乐不都让这个过程“半中间发生阻隔、停顿或故障而断开”了吗？这不就是活生生的“中断”吗？
在这个场景中，我是唯一具有处理能力的主体，不管是烧水、关水龙头还是看电视，同一个时间点上我只能干一件事情。但是，在我专心致志干一件事情时，总有许多或紧迫或不紧迫的事情突然出现在面前，都需要去关注，有些还需要我停下手头的工作马上去处理。只有在处理完之后，方能回头完成先前的任务，“把一壶水彻底烧开！”
中断机制不仅赋予了我处理意外情况的能力，如果我能充分发挥这个机制的妙用，就可以“同时”完成多个任务了。回到烧水的例子，实际上，无论我在不在厨房，煤气灶总是会把水烧开的，我要做的，只不过是及时关掉煤气灶而已，为了这么一个一秒钟就能完成的动作，却让我死死地守候在厨房里，在10分钟的时间里不停地看壶嘴是不是冒蒸气，怎么说都不划算。我决定安下心来看电视。当然，在有生之年，我都不希望让厨房成为火海，于是我上了闹钟，10分钟以后它会发出“尖叫”，提醒我炉子上的水烧开了，那时我再去关煤气也完全来得及。我用一个中断信号——闹铃——换来了10分钟的欢乐时光，心里不禁由衷地感叹：中断机制真是个好东西。
正是由于中断机制，我才能有条不紊地“同时”完成多个任务，中断机制实质上帮助我提高了并发“处理”能力。它也能给计算机系统带来同样的好处：如果在键盘按下的时候会得到一个中断信号，CPU就不必死守着等待键盘输入了；如果硬盘读写完成后发送一个中断信号，CPU就可以腾出手来集中精力“服务大众”了——无论是人类敲打键盘的指尖还是来回读写介质的磁头，跟CPU的处理速度相比，都太慢了。没有中断机制，就像我们苦守厨房一样，计算机谈不上有什么并行处理能力。
跟人相似，CPU也一样要面对纷繁芜杂的局面——现实中的意外是无处不在的——有可能是用户等得不耐烦，猛敲键盘；有可能是运算中碰到了0除数；还有可能网卡突然接收到了一个新的数据包。这些都需要CPU具体情况具体分析，要么马上处理，要么暂缓响应，要么置之不理。无论如何应对，都需要CPU暂停“手头”的工作，拿出一种对策，只有在响应之后，方能回头完成先前的使命，“把一壶水彻底烧开！”
先让我们感受一下中断机制对并发处理带来的帮助。
让我们用程序来探讨一下烧水问题，如果没有“中断”（注意，我们这里只是模仿中断的场景，实际上是用异步事件——消息——处理机制来展示中断产生的效果。毕竟，在用户空间没有办法与实际中断产生直接联系，不过操作系统为用户空间提供的异步事件机制，可以看作是模仿中断的产物），设计如下：
void StayInKitchen()
{
bool WaterIsBoiled = false;
while ( WaterIsBoiled != true )
{
// 关煤气炉
printf(“Close gas oven.\n”);
// 一切安定下来，终于可以看电视了，10分钟的宝贵时间啊，逝者如斯夫…
watching_tv();
return;
}
可以看出，整个流程如同我们前面描述的一样，所有工作要顺序执行，没有办法完成并发任务。
如果用“中断”，在开始烧水的时候设定一个10分钟的“闹铃”，然后让CPU去看电视（有点难度，具体实现不在我们关心的范围之内，留给读者自行解决吧：>）。等闹钟响的时候再去厨房关炉子。
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <signal.h>
#include <stdio.h>
// 闹钟到时会执行此程序
void sig_alarm(int signo)
{
//关煤气炉
printf(“Close gas oven.\n”);
}
void watching_tv()
{
while(1)
{
// 呵呵，悠哉悠哉
}
}
int main()
{
// 点火后设置定时中断
printf(“Start to boil water, set Alarm”);
if (signal( SIGALRM, sig_alrm ) == SIG_ERR)
{
perror("signal(SIGALRM) error");
return -1;
}
// 然后就可以欣赏电视节目了
printf(“Watching TV!\n”);
watching_tv();
return 0;
}
这两段程序都在用户空间执行。第二段程序跟中断也没有太大的关系，实际上它只用了信号机制而已。但是，通过这两个程序的对比，我们可以清楚地看到异步事件的处理机制是如何提升并发处理能力的。
Alarm定时器：alarm相当于系统中的一个定时器，如果我们调用alarm(5)，那么5秒钟后就会“响起一个闹铃”（实际上靠信号机制实现的，我们这里不想深入细节，如果你对此很感兴趣，请参考Richard Stevens不朽著作《Unix环境高级编程》）。在闹铃响起的时候会发生什么呢?系统会执行一个函数，至于到底是什么函数，系统允许程序自行决定。程序员编写一个函数，并调用signal对该函数进行注册，这样一旦定时到来，系统就会调用程序员提供的函数（CallBack函数？没错，不过在这里如何实现并不关键，我们就不引入新的概念和细节了）。上面的例子里我们提供的函数是sig_alarm，所做的工作很简单，打印“关闭煤气灶”消息。
上面的两个例子很简单，但很能说明问题，首先，它证明采用异步的消息处理机制可以提高系统的并发处理能力。更重要的是，它揭示了这种处理机制的模式。用户根据需要设计处理程序，并可以将该程序和特定的外部事件绑定起来，在外部事件发生时系统自动调用处理程序，完成相关工作。这种模式给系统带来了统一的管理方法，也带来无尽的功能扩展空间。
一、中断是什么
中断的汉语解释是半中间发生阻隔、停顿或故障而断开。那么，在计算机系统中，我们为什么需要“阻隔、停顿和断开”呢？
举个日常生活中的例子，比如说我正在厨房用煤气烧一壶水，这样就只能守在厨房里，苦苦等着水开——如果水溢出来浇灭了煤气，有可能就要发生一场灾难了。等啊等啊，外边突然传来了惊奇的叫声“怎么不关水龙头？”于是我惭愧的发现，刚才接水之后只顾着抱怨这份无聊的差事，居然忘了这事，于是慌慌张张的冲向水管，三下两下关了龙头，声音又传到耳边，“怎么干什么都是这么马虎？”。伸伸舌头，这件小事就这么过去了，我落寞的眼神又落在了水壶上。
门外忽然又传来了铿锵有力的歌声，我最喜欢的古装剧要开演了，真想夺门而出，然而，听着水壶发出“咕嘟咕嘟”的声音，我清楚：除非等到水开，否则没有我享受人生的时候。
这个场景跟中断有什么关系呢？
如果说我专心致志等待水开是一个过程的话，那么叫声、电视里传出的音乐不都让这个过程“半中间发生阻隔、停顿或故障而断开”了吗？这不就是活生生的“中断”吗？
在这个场景中，我是唯一具有处理能力的主体，不管是烧水、关水龙头还是看电视，同一个时间点上我只能干一件事情。但是，在我专心致志干一件事情时，总有许多或紧迫或不紧迫的事情突然出现在面前，都需要去关注，有些还需要我停下手头的工作马上去处理。只有在处理完之后，方能回头完成先前的任务，“把一壶水彻底烧开！”
中断机制不仅赋予了我处理意外情况的能力，如果我能充分发挥这个机制的妙用，就可以“同时”完成多个任务了。回到烧水的例子，实际上，无论我在不在厨房，煤气灶总是会把水烧开的，我要做的，只不过是及时关掉煤气灶而已，为了这么一个一秒钟就能完成的动作，却让我死死地守候在厨房里，在10分钟的时间里不停地看壶嘴是不是冒蒸气，怎么说都不划算。我决定安下心来看电视。当然，在有生之年，我都不希望让厨房成为火海，于是我上了闹钟，10分钟以后它会发出“尖叫”，提醒我炉子上的水烧开了，那时我再去关煤气也完全来得及。我用一个中断信号——闹铃——换来了10分钟的欢乐时光，心里不禁由衷地感叹：中断机制真是个好东西。
正是由于中断机制，我才能有条不紊地“同时”完成多个任务，中断机制实质上帮助我提高了并发“处理”能力。它也能给计算机系统带来同样的好处：如果在键盘按下的时候会得到一个中断信号，CPU就不必死守着等待键盘输入了；如果硬盘读写完成后发送一个中断信号，CPU就可以腾出手来集中精力“服务大众”了——无论是人类敲打键盘的指尖还是来回读写介质的磁头，跟CPU的处理速度相比，都太慢了。没有中断机制，就像我们苦守厨房一样，计算机谈不上有什么并行处理能力。
跟人相似，CPU也一样要面对纷繁芜杂的局面——现实中的意外是无处不在的——有可能是用户等得不耐烦，猛敲键盘；有可能是运算中碰到了0除数；还有可能网卡突然接收到了一个新的数据包。这些都需要CPU具体情况具体分析，要么马上处理，要么暂缓响应，要么置之不理。无论如何应对，都需要CPU暂停“手头”的工作，拿出一种对策，只有在响应之后，方能回头完成先前的使命，“把一壶水彻底烧开！”
先让我们感受一下中断机制对并发处理带来的帮助。
让我们用程序来探讨一下烧水问题，如果没有“中断”（注意，我们这里只是模仿中断的场景，实际上是用异步事件——消息——处理机制来展示中断产生的效果。毕竟，在用户空间没有办法与实际中断产生直接联系，不过操作系统为用户空间提供的异步事件机制，可以看作是模仿中断的产物），设计如下：
void StayInKitchen()
{
bool WaterIsBoiled = false;
while ( WaterIsBoiled != true )
{
bool VaporGavenOff = false;
if (VaporGavenOff )
elseWaterIsBoiled = true;
WaterIsBoiled = false;}
// 关煤气炉
printf(“Close gas oven.\n”);
// 一切安定下来，终于可以看电视了，10分钟的宝贵时间啊，逝者如斯夫…
watching_tv();
return;
}
可以看出，整个流程如同我们前面描述的一样，所有工作要顺序执行，没有办法完成并发任务。
如果用“中断”，在开始烧水的时候设定一个10分钟的“闹铃”，然后让CPU去看电视（有点难度，具体实现不在我们关心的范围之内，留给读者自行解决吧：>）。等闹钟响的时候再去厨房关炉子。
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <signal.h>
#include <stdio.h>
// 闹钟到时会执行此程序
void sig_alarm(int signo)
{
//关煤气炉
printf(“Close gas oven.\n”);
}
void watching_tv()
{
while(1)
{
// 呵呵，悠哉悠哉
}
}
int main()
{
// 点火后设置定时中断
printf(“Start to boil water, set Alarm”);
if (signal( SIGALRM, sig_alrm ) == SIG_ERR)
{
perror("signal(SIGALRM) error");
return -1;
}
// 然后就可以欣赏电视节目了
printf(“Watching TV!\n”);
watching_tv();
return 0;
}
这两段程序都在用户空间执行。第二段程序跟中断也没有太大的关系，实际上它只用了信号机制而已。但是，通过这两个程序的对比，我们可以清楚地看到异步事件的处理机制是如何提升并发处理能力的。
Alarm定时器：alarm相当于系统中的一个定时器，如果我们调用alarm(5)，那么5秒钟后就会“响起一个闹铃”（实际上靠信号机制实现的，我们这里不想深入细节，如果你对此很感兴趣，请参考Richard Stevens不朽著作《Unix环境高级编程》）。在闹铃响起的时候会发生什么呢?系统会执行一个函数，至于到底是什么函数，系统允许程序自行决定。程序员编写一个函数，并调用signal对该函数进行注册，这样一旦定时到来，系统就会调用程序员提供的函数（CallBack函数？没错，不过在这里如何实现并不关键，我们就不引入新的概念和细节了）。上面的例子里我们提供的函数是sig_alarm，所做的工作很简单，打印“关闭煤气灶”消息。
上面的两个例子很简单，但很能说明问题，首先，它证明采用异步的消息处理机制可以提高系统的并发处理能力。更重要的是，它揭示了这种处理机制的模式。用户根据需要设计处理程序，并可以将该程序和特定的外部事件绑定起来，在外部事件发生时系统自动调用处理程序，完成相关工作。这种模式给系统带来了统一的管理方法，也带来无尽的功能扩展空间。
扫一扫
1561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
