中断处理程序为什么不能阻塞休眠？？？以前真没认真思考过！

cskyrain

一直认为中断处理函数不能休眠的是天经地义的，可从没认真思考过问什么不能休眠，阻塞。最近看了一下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
感觉他把中端不能休眠的原因都归结为可支持中断处理程序的嵌套上了。那是不是可以这样理解，如果不支持中断嵌套，中断处理程序就可以休眠了，呵呵呵，貌似这样也不对吧，
问题：中断处理程序不能休眠的原因究竟是什么呢？

openspace

中断处理对应的是实时性比较高的场景
以时钟中段为例，如果阻塞了，那么时钟jiffies就不准确了
再以键盘输入为例，如果阻塞，作为用户长时间看不到自己的输入的话感觉会非常糟糕

cskyrain

ls的说法就是说只和实时性有关系，和中断嵌套什么的没关了，那ulk的解释有如何理解呢？

那是不是可以这么理解，其实如果想在中断处理函数中休眠也是能够实现的，只是因为我们为了快速的处理中断请求，而强制性的不去这么做。

ps：在中断中休眠能过带来什么问题呢？？？按照ls的说法是不是只会降低中断处理的效率。会不会内核崩溃呢？？

[ 本帖最后由 cskyrain 于 2009-11-24 21:26 编辑 ]

mik

中断不能被阻塞，要看什么情形之下：


1、大部分情况下，中断里不允许再发生中断，中断发生后 processor 会屏蔽“可屏蔽中断”，拒绝响向其它“可屏蔽中断”。

2、在中断发生另一个异常，是不能被屏蔽的。

   例如：在一个中断处理程序里，发生了一个缺页异常。processor 必须去响应 #PF 异常

3、如果是 trap 类型的中断例程，是可以响应“可屏蔽中断”。

----------------------------------------------------------------------------

所以：在中断处理程序中，是不可能发生进程序切换的。（processor 保证），除非是 trap 类型

      但如发生 exception，则必须去响应发生的 exception （异常）

specter117

强制在中断处理函数里调用schedule()还是可以的吧，只不过此中断在执行完毕之前不能再得到相应

snail_314

你的因怎么推断出你的果的？
好像两者没关系

mik

你说说看，进程是怎样调度的？

snail_314

我的想法是，一个进程能失去处理器控制，只有两种情况，一种是“被”剥夺，就是在用户态时，tick到了，按照等时调度策略，这个进程需要让出处理器资源了。第二种就是该进程“主动”让出处理器资源。而假如在中断发生睡眠，因为中断“物理”上是“代表”当前的进程的，因为中断的内核栈就是当前进程的内核栈。但是逻辑意义上中断不应该代表当前进程，假如你中断里主动放弃处理器，那岂不是无形中惩罚了这个无辜的进程。所以，我觉得这是在设计上的原因，而非实现上。

snail_314

调用schedule函数，里面只是保存context，偷换esp，然后一个ret。和trap有什么关系？

mik

原帖由 snail_314 于 2009-11-24 22:39 发表
调用schedule函数，里面只是保存context，偷换esp，然后一个ret。和trap有什么关系？

谁调用 schedule() ？