中断的汉语解释是半中间发生阻隔、停顿或故障而断开。那么,在
计算机系统中,我们为什么需要“阻隔、停顿和断开”呢?
举个日常生活中的例子,比如说我正在厨房用煤气烧一壶水,这样就只能守在厨房里,苦苦等着水开——如果水溢出来浇灭了煤气,有可能就要发生一场灾难了。等啊等啊,外边突然传来了惊奇的叫声“怎么不关水龙头?”于是我惭愧的发现,刚才接水之后只顾着抱怨这份无聊的差事,居然忘了这事,于是慌慌张张的冲向水管,三下两下关了龙头,声音又传到耳边,“怎么干什么都是这么马虎?”。伸伸舌头,这件小事就这么过去了,我落寞的眼神又落在了水壶上。
门外忽然又传来了铿锵有力的歌声,我最喜欢的古装剧要开演了,真想夺门而出,然而,听着水壶发出“咕嘟咕嘟”的声音,我清楚:除非等到水开,否则没有我享受人生的时候。
这个场景跟中断有什么关系呢?
如果说我专心致志等待水开是一个过程的话,那么叫声、电视里传出的音乐不都让这个过程“半中间发生阻隔、停顿或故障而断开”了吗?这不就是活生生的“中断”吗?
在这个场景中,我是唯一具有处理能力的主体,不管是烧水、关水龙头还是看电视,同一个时间点上我只能干一件事情。但是,在我专心致志干一件事情时,总有许多或紧迫或不紧迫的事情突然出现在面前,都需要去关注,有些还需要我停下手头的工作马上去处理。只有在处理完之后,方能回头完成先前的任务,“把一壶水彻底烧开!”
中断机制不仅赋予了我处理意外情况的能力,如果我能充分发挥这个机制的妙用,就可以“同时”完成多个任务了。回到烧水的例子,实际上,无论我在不在厨房,煤气灶总是会把水烧开的,我要做的,只不过是及时关掉煤气灶而已,为了这么一个一秒钟就能完成的动作,却让我死死地守候在厨房里,在10分钟的时间里不停地看壶嘴是不是冒蒸气,怎么说都不划算。我决定安下心来看电视。当然,在有生之年,我都不希望让厨房成为火海,于是我上了闹钟,10分钟以后它会发出“尖叫”,提醒我炉子上的水烧开了,那时我再去关煤气也完全来得及。我用一个中断信号——
闹铃——换来了10分钟的
欢乐时光,心里不禁由衷地感叹:
中断机制真是个好东西。
正是由于
中断机制,我才能有条不紊地“同时”完成多个任务,中断机制实质上帮助我提高了并发“处理”能力。它也能给
计算机系统带来同样的好处:如果在键盘按下的时候会得到一个中断信号,CPU就不必死守着等待键盘输入了;如果硬盘读写完成后发送一个中断信号,CPU就可以腾出手来集中精力“服务大众”了——无论是人类敲打键盘的指尖还是来回读写介质的磁头,跟CPU的处理速度相比,都太慢了。没有
中断机制,就像我们苦守厨房一样,计算机谈不上有什么
并行处理能力。
跟人相似,CPU也一样要面对纷繁芜杂的局面——现实中的意外是无处不在的——有可能是用户等得不耐烦,猛敲键盘;有可能是运算中碰到了0除数;还有可能网卡突然接收到了一个新的数据包。这些都需要CPU具体情况具体分析,要么马上处理,要么暂缓响应,要么置之不理。无论如何应对,都需要CPU暂停“手头”的工作,拿出一种对策,只有在响应之后,方能回头完成先前的使命,“把一壶水彻底烧开!”
然后说下 轮询模式
刚才中断已经解释了,硬件跟 CPU 通信的大致原理,
但是如果 中断信号过于频繁,而且中断后处理的数据过于小.比如 一个网卡遭到 小IP 包的攻击,每秒10万个包,都是64字节的小包,
这个时候再强的 CPU 也会累死的,
因为 CPU 的发展一直在提升 处理数据的能力上,
中断机制 从来没有改变过.
所以 早期的时候,UNIX 系统提出了
软中断的概念,类似与 硬件的信号缓存,
在 内存为每一个 使用中断的硬件都 开辟一个缓存,
当需要
中断处理的时候,信号是被放在缓存里,而不是直接交给CPU ,当缓存差不多快满的时候,让CPU 一次来处理完,而不用一个中断 处理一次,大大减少了 CPU 的压力.
所以 FREEBSD 4.11的时候,有人做过攻击试验.100M 流量的攻击包,在 BSD 系统没开 轮询的时候,CPU 占用 85%,开了轮询后,CPU 占用 3%--5%
轮询方式的基本概念
轮询(Polling)I/O方式或程序控制I/O方式,是让CPU以一定的周期按次序查询每一个外设,看它是否有数据输入或输出的要求,若有,则进行相应的输入/输出服务;若无,或I/O处理完毕柏,CPU就接着查询下一个外设。
所需硬件:外设接口提供状态端口、数据端口
软件机制:应用程序必须定时查询各个接口的状态端口,判断是否需要输入、输出数据,如果需要,则通过数据端口进行数据操作。
特点:CPU通过执行指令主动对外部设备进行查询,外部设备处于被动地位。