- 论坛徽章:
- 0
|
一直认为中断处理函数不能休眠的是天经地义的,可从没认真思考过问什么不能休眠,阻塞。最近看了一下ulk中对这个的解释,感觉还是有点不太明白,
“The price to pay for allowing nested kernel control paths is that an interrupt handler must never block, that is, no process switch can take place until an interrupt handler is running. In fact, all the data needed to resume a nested kernel control path is stored in the Kernel Mode stack, which is tightly bound to the current process.”
上面把中断处理程序不能休眠归结为中断处理程序可以嵌套,而恢复嵌套的中断处理程序的相关数据放在内核态堆栈中,这个栈和当前进程相关联,这里有一点不明白,既然有栈存储数据,而且进程切换出去后,这个栈也不会被销毁,等进程在切回来时,不同样可以是嵌套的中断处理程序返回吗?(这里先不考了中断处理时间的太长,影响对中断处理的服务问题,只说明中断是否可休眠)。同时我google一下,看到有人对中断不能休眠的以一种解释:
”
中断处理程序用到的所有数据有保存在当前进程的内核堆栈中(一般情况下),如果此时发生了
进程切换,中断处理程序将被阻塞, 当在一次发生进程切换时,不一定马上就换回来。比如当
发生一个键盘中断时,键盘处理程序正在进行,此时又恰好发生了进程抢占,切换到了另一个进程
中,假如那个进程不会引起内核的稳定,那么中断处理程序将一直阻塞,内禾根本就没法响应那个中断,
直到在一次发生进程切换。假设最后又切换回执行中断处理程序的那个进程中时,如果它的内核堆栈
受到了无意的破坏怎么办呢?那中断处理程序可能无法在继续运行下去了,此次中断服务失败。而且
现在的处理程序都允许中断嵌套,一个中断被阻塞,其它的都将被阻塞。所以面对错综复杂的内核逻辑,
最好的办法就是在中断处理程序中禁止发生进程切换,这样既提高了中断处理程序的响应速度,也增加了
内核的稳定性与安全性。
“
我感觉他的理由有两个:一个事效率,可能影响处理速度,另一就是:如果它的内核堆栈
受到了无意的破坏怎么办?
对于第一种理由先不讨论,
可第二种,理由我感觉很牵强,如果栈那么容易破坏,哪我也可以说描述进程的数据结构什么的也可能被破坏,哪岂不是进程调度都是不安全的了,
这样按他的说法,就只有第一个效率的原因了。
回到ulk的解释,不知道是不是我理解的有问题,The price to pay for allowing nested kernel control paths is that an interrupt handler must never block
感觉他把中端不能休眠的原因都归结为可支持中断处理程序的嵌套上了。那是不是可以这样理解,如果不支持中断嵌套,中断处理程序就可以休眠了,呵呵呵,貌似这样也不对吧,
问题:中断处理程序不能休眠的原因究竟是什么呢? |
|