《i386模式下Linux中断讲解.docVIP

小弟自知资质愚钝, 以下乃个人研读了Linux内核源代码后的体会,不妥之处还请各位批评指点,顺便说说,小弟报考的中国4所电子科大之一的杭州电子科技大学, 4:1的录取比例让我压力非常大,冲刺了. 中断是什么 中断的汉语解释是半中间发生阻隔, 停顿或故障而断开. 那么, 在计算机系统中, 我们为什么需要“阻隔, 停顿和断开”呢？ 举个日常生活中的例子, 比如说我正在厨房用煤气烧一壶水, 这样就只能守在厨房里, 苦苦等着水开——如果水溢出来浇灭了煤气, 有可能就要发生一场灾难了. 等啊等啊, 外边突然传来了惊奇的叫声“怎么不关水龙头？”于是我惭愧的发现, 刚才接水之后只顾着抱怨这份无聊的差事, 居然忘了这事, 于是慌慌张张的冲向水管, 三下两下关了龙头, 声音又传到耳边, “怎么干什么都是这么马虎？”. 伸伸舌头, 这件小事就这么过去了, 我落寞的眼神又落在了水壶上. 门外忽然又传来了铿锵有力的歌声, 我最喜欢的古装剧要开演了, 真想夺门而出, 然而, 听着水壶发出“咕嘟咕嘟”的声音, 我清楚: 除非等到水开, 否则没有我享受人生的时候. 这个场景跟中断有什么关系呢？ 如果说我专心致志等待水开是一个过程的话, 那么叫声, 电视里传出的音乐不都让这个过程“半中间发生阻隔, 停顿或故障而断开”了吗？这不就是活生生的“中断”吗？ 在这个场景中, 我是唯一具有处理能力的主体, 不管是烧水, 关龙头还是看电视, 同一个时间点上我只能干一件事情. 但是, 在我专心致志干一件事情时, 总有许多或紧迫或不紧迫的事情突然出现在面前, 都需要去关注, 有些还需要我停下手头的工作马上去处理. 只有在处理完之后, 方能回头完成先前的任务, “把一壶水彻底烧开! ” 中断机制不仅赋予了我处理意外情况的能力, 如果我能充分发挥这个机制的妙用, 就可以“同时”完成多个任务了. 回到烧水的例子, 实际上, 无论我在不在厨房, 煤气灶总是会把水烧开的, 我要做的, 只不过是及时关掉煤气灶而已, 为了这么一个一秒钟就能完成的动作, 却让我死死的守候在厨房里, 在10分钟的时间里不停的看壶嘴是不是冒蒸汽, 怎么说都不划算. 我决定安下心来看电视. 当然, 在有生之年, 我都不希望让厨房成为火海, 于是我上了闹钟, 10分钟以后它会发出“尖叫”, 提醒我炉子上的水烧开了, 那时我再去关煤气也完全来得及. 我用一个中断信号——闹铃——换来了10分钟的欢乐时光, 心里不禁由衷的感叹: 中断机制真是个好东西. 正是由于中断机制, 我才能有条不紊的“同时”完成多个任务, 中断机制实质上帮助我提高了并发“处理”能力. 它也能给计算机系统带来同样的好处: 如果在键盘按下的时候会得到一个中断信号, CPU就不必死守着等待键盘输入了；如果硬盘读写完成后发送一个中断信号, CPU就可以腾出手来集中精力“服务大众”了——无论是人类敲打键盘的指尖还是来回读写介质的磁头, 跟CPU的处理速度相比, 都太慢了. 没有中断机制, 就像我们苦守厨房一样, 计算机谈不上有什么的并行处理能力. 跟人相似, CPU也一样要面对纷繁芜杂的局面——现实中的意外是无处不在的——有可能是用户等得不耐烦, 猛敲键盘；有可能是运算中碰到了0除数；还有可能网卡突然接收到了一个新的数据包. 这些都需要CPU具体情况具体分析, 要么马上处理, 要么暂缓响应, 要么置之不理. 无论如何应对, 都需要 CPU暂停“手头”的工作, 拿出一种对策, 只有在响应之后, 方能回头完成先前的使命, “把一壶水彻底烧开! ” 先让我们感受一下中断机制对并发处理带来的帮助. 让我们用程序来探讨一下烧水问题, 如果没有“中断”(注意, 我们这里只是模仿中断的场景, 实际上是用异步事件——消息——处理机制来展示中断产生的效果. 毕竟, 在用户空间没有办法与实际中断产生直接联系, 不过操作系统为用户空间提供的异步事件机制, 可以看作是模仿中断的产物), 设计如下: void StayInKitchen() { bool WaterIsBoiled = false; while ( WaterIsBoiled != true ) { bool VaporGavenOff = false; if (VaporGavenOff ) WaterIsBoiled = true; else WaterIsBoiled = false; } // 关煤气炉 printf(“Close gas oven.\n”); // 一切安定下来, 终于可以看电视了, 10分钟的宝贵时间啊, 逝者如斯夫… watch