接触到的技术多了,会发现很多异曲同工的东西。
最近在看Linux内核,看到中断和异常这块,想起来了以前体系结构课上讲到的关于轮询和中断的概念。二者都是操作系统和硬件交互的方式。开始时是轮询的方法,内核(通常是驱动)需要自己去轮询硬件看硬件是否有事件,如果有则处理,没有则继续轮询,直到被操作系统挂起。这显然是很低效的。于是有了中断这种更好的方案。
但我认为中断本质上仍然是轮询,只不过是把轮询操作放在了硬件层,提高了轮询的效率。中断是如何实现的?通过IRQ(Interrup ReQuest),IRQ其实就是一个硬件的轮询系统,它连接了所有的硬件,每个硬件分配一个独立的IRQ编号。硬件有消息就会放在它自己的IRQ里。然后CPU会在每个指令周期结束时查看IRQ里是否有消息,如果有就触发中断给内核去处理。
这就让我联想到了IO复用epoll。以前的poll/select之所以低效是因为要在应用层遍历所有socket的状态。epoll只不过是把这个过程交给内核,内核只把有新输入输出的socket fd返回给应用层,应用层不再需要遍历所有socket fd,从而提高了效率。
再比如游戏里,在脚本层写tick很影响效率。于是把tick的逻辑尽量放在引擎层,然后利用事件与脚本交互。例如要在主角播放攻击动画的第n帧判定是否击中,简单的做法是在脚本里每帧去检查,然后到第n帧的时候执行操作。更高效的做法是让引擎去做每帧检查的任务,脚本层只需要给引擎注册一个回调,当播放到第n帧的时候,引擎调用回调即可。但本质上,仍然是轮询,只不过把轮询向下移动了一层,在执行更快速的地方轮询。
总结一下就是:当主体需要了解客体的状态,而主体并不能直接接收到客体的消息时,主体的轮询是无法避免的。主体所能做的是尽可能把轮询的操作放在更底层,这样才可以提高效率。