为什么在中断上下文中不能休眠?

2.schedule()在切换进程时，保存当前的进程上下文(CPU寄存器的值、进程的状态以及堆栈中的内容),以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文(在调用中断处理程序后恢复)；但在中断处理程序里，CPU寄存器的值肯定已经变化了吧(最重要的程序计数器PC、堆栈SP等)，如果此时因为睡眠或阻塞 *** 作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。3.2.4内核中schedule()函数本身在进来的时候判断是否处于中断上下文:if(unlikely(in_interrupt()))BUG()因此,强行调用schedule()的结果就是内核BUG,但我看2.6.18的内核schedule()的实现却没有这句,改掉了.4.中断handler会使用被中断的进程内核堆栈,但不会对它有任何影响,因为handler使用完后会完全清除它使用的那部分堆栈,恢复被中断前的原貌.5.处于中断context时候,内核是不可抢占的,因此,如果休眠,则内核一定挂起.----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------先把中断处理流程给出来1.进入中断处理程序---2.保存关键上下文----3.开中断（sti指令）---4.进入中断处理程序的 handler---5.关中断（cli指令）----6.写EOI寄存器（表示中断处理完成）----7.开中断。复制代码硬中断：对应于上图的1、2、3步骤，在这几个步骤中，所有中断是被屏蔽的，如果在这个时候睡眠了， *** 作系统不会收到任何中断（包括时钟中断），系统就基本处于瘫痪状态（例如调度器依赖的时钟节拍没有等等）软中断：对应上图的4（当然，准确的说应该是4步骤的后面一点，先把话说保险点，免得思一克又开始较真）。这个时候不能睡眠的关键是因为上下文。大家知道 *** 作系统以进程调度为单位，进程的运行在进程的上下文中，以进程描述符作为管理的数据结构。进程可以睡眠的原因是 *** 作系统可以切换不同进程的上下文，进行调度 *** 作，这些 *** 作都以进程描述符为支持。中断运行在中断上下文，没有一个所谓的中断描述符来描述它，它不是 *** 作系统调度的单位。一旦在中断上下文中睡眠，首先无法切换上下文（因为没有中断描述符，当前上下文的状态得不到保存），其次，没有人来唤醒它，因为它不是 *** 作系统的调度单位。此外，中断的发生是非常非常频繁的，在一个中断睡眠期间，其它中断发生并睡眠了，那很容易就造成中断栈溢出导致系统崩溃。如 果上述条件满足了（也就是有中断描述符，并成为调度器的调度单位，栈也不溢出了，理论上是可以做到中断睡眠的），中断是可以睡眠的，但会引起很多问题.例 如，你在时钟中断中睡眠了，那 *** 作系统的时钟就乱了，调度器也了失去依据；例如，你在一个IPI（处理器间中断）中，其它CPU都在死循环等你答复，你确 睡眠了，那其它处理器也不工作了；例如，你在一个DMA中断中睡眠了，上面的进程还在同步的等待I/O的完成，性能就大大降低了还可以举出很多例子。 所以，中断是一种紧急事务，需要 *** 作系统立即处理，不是不能做到睡眠，是它没有理由睡眠。中断产生是随机的，假设某次中断一个内核线程，而且按照你说的方案，这个线程的task结构就会被借用，线程就会去睡眠。被打断线程的优先级如果太低，那 么它很难有机会再执行，某些情况下可能造成系统hang。如果临时提高被打断线程的优先级，那么又需要设计新的唤醒机制来保证阻塞同一锁上的高优先级的线 程被先唤醒。同时，要实现临时提高被打断线程的优先级，又需要再锁的获取流程增加改变优先级的算法。

至于中断为什么不能进入休眠，今天再网上查阅并总结了一下：

中断处理的时候,不应该发生进程切换,因为在中断上下文中,唯一能打断当前中断handler的只有更高优先级的中断,

它不会被进程打断(这点对于softirq,tasklet也一样,因此这些bottom half也不能休眠),如果在中断上下文中休眠,则

没有办法唤醒它,因为所有的wake_up_xxx都是针对某个进程而言的,而在中断上下文中,没有进程的概念,没有相应的

task_struct(这点对于softirq和tasklet一样),因此真的休眠了,比如调用了会导致阻塞的例程,内核几乎肯定会死.

---