关于LINUX在中断（硬软）中不能睡眠的真正原因

lucasman

看看 http://product.china-pub.com/301691
里面对 中断 可睡眠与否的解说吧。很清楚的。



5.1.3  中断中断中断中断和和和和异常的对比      异常的对比      异常的对比      异常的对比
是否可睡眠      是否可睡眠      是否可睡眠      是否可睡眠：由于异常为同步事件，由当前进程执行所引发，所以可以说，异
常处于被打断进程的上下文之中，为当前被打断的进程服务，所以在异常处理过程
中，可以调用任何内核态的函数，也可以睡眠。因为睡眠时有意义的，同时也是合
理的；而中断为异步事件，虽然使用当前被打断进程的内核栈、处于被打断进程的
上下文之中，但是和当前被中断进程没有必然的关系，同时中断处理程序和外部的
一个具体设备相对应，这就要求中断处理程序能快速的完成，以便能及时地响应设
备的下一次中断请求，所以在中断处理过程中是不可以睡眠的，也就是说终端处理
程序不能睡眠的根本原因在于中断处理程序必须运行的尽可能的快，以不丢失设备
的中断请求。从另外的一个角度进行考虑，假设中断处理程序由于调用了一个可以
睡眠的内核态函数，进而睡眠了，那么被该中断处理程序打断的用户进程必定也随
之睡眠，当导致睡眠的原因消失后，那么唤醒被中断处理程序所打断的的用户进程
即可运行睡眠的中断处理程序。但是有两点需要考虑：1：睡眠过程一定会丢失外设
的中断请求。2：此时的中断处理并不是为用户进程服务的，但是会将中断处理程序
所使用的系统资源记账到用户进程中去，这是不合理的；对比异常处理过程，因为
异常处理是为用户进程服务的，所以将异常处理过程所使用的系统资源记账到用户
进程是合理的。

经过上面的分析和讨论，我们可以给出结果：异常处理过程可以睡眠；中断处
理过程不可以睡眠。


回复 1# 思一克


   

lucasman

也就是说 你可以让中断上半部处理过程中睡眠。但是你要考虑的后果，并做处理。

这样会让系统处理逻辑更复杂（要释放相关的临界资源）。

从另一个角度讲， 现在的上半部，下半部的划分。就是为了实现中断处理过程中可以调用的可能睡眠的函数。

lucasman 发表于 2012-10-10 16:53
看看 http://product.china-pub.com/301691
里面对 中断 可睡眠与否的解说吧。很清楚的。

vsoloo

金典讨论～

fengzheyu

回复 16# 思一克


    中断用的不也是进程的内核栈吗，这样的话，当这个进程被重新调度的话，应该可以继续执行中断啊，

fengzheyu

读完了，不知之前的几位大牛现在都是干什么呢，  这种讨论贴子太好了，要是咱们国人都这个样，牛b了

_nosay

ljldx 发表于 2012-10-08 22:32
我是来看高手讨论的

我也是。

jieniyisheng521

最新ｌｉｎｕｘ内核为保证任务的实时性，把中断线程化，这样中断是可以睡眠的，也可以被抢占的．回复 1# 思一克


   

mordorwww

回复 19# xiaozhaoz



这个是什么意思，跟CFS有关？


如果realtime patch合并到主流内核中, 可以满足: 系统中优先级高的任务, 被**后, 在很小的可控的延时内, CS:eip指令得到执行.

但不能保证低优先级的时延, 这正是CFS要解决的问题, 设想一下, 要让系统中的任何优先级的任务在一定的时间内得到执行, 必然要求等待时间长的任务优先得到执行, CFS就是用等待时间来作为调度的依据, 而优先级居次. 有时间在讨论CFS的实现.



   

mordorwww

思一克 发表于 2007-06-28 17:11
LINUX中到是有中断还没有完全返回就调用schedule()而睡眠过去的例子。

可以猜是哪里。

挖坟
在哪里?

mordorwww

Au_Hank 发表于 2007-09-03 08:19
中断本来就是用来处理紧急/突发事件的, 而进程睡眠是因为没有事情可以做才去睡眠的,
两者本来就属于对立的 ...

进程有活干也会被抢占阿
被内核抢占
被其它进程抢占