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

思一克

中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。
你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？

原帖由 zx_wing 于 2007-6-28 10:56 发表于 29楼  

此外，我想lz对上下文一词还有点误解。
上下文（context）表示当前cpu的状态，包括各种标志及寄存器的值。这里中断是运行在自己的上下文而不是进程的上下文。如果是运行在进程上下文的话，中断处理就不需要在 ...

xiaozhaoz

原帖由 zx_wing 于 2007-6-28 10:37 发表于 27楼  

>>这其实和"中断没有自己的上下文"无关. CPU没有关中断, 中断有自己的上下文, 中断的上下文就是抢占的任务A的上下文.

“中断没有自己的上下文”，呵呵，我没有说这句话哈。lz很多立论在这 ...

中断sleep了, 由谁来唤醒?
在关中断的情况下, 不能sleep, 19楼已经描述了.
在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的:
如果内核修改好了, handler中调用schedule_timeout_interrupt().的情况.

中断都很紧急, 这不一定正确,

不是所有的中断handler都紧急, 就如solaris中描述的, 时钟中断最紧急, 其他的中断不一定. 可能有的实时任务比中断紧急.

中断没有上下文确实不是你说的, sorry.

zx_wing

原帖由 思一克 于 2007-6-28 11:05 发表于 31楼  
中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。
你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？

不好意思，我看贴也不仔细，把lz“总结:
    异步异常(中断)handler不是没有上下文, 而是没有固定的上下文,  如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.”这句话看成中断使用进程上下文了。

xiaozhaoz

原帖由 思一克 于 2007-6-28 11:05 发表于 31楼  
中断当然有自己的CONTEXT。但没有（准确说经常没有）进程相关的CONTEXT。
你看2.6.13 KERNEL，IRQ使用 自己的STACK，如果在中断中schedule()了，能正确回来吗？

你再编译的时候, 把4K的stack的选项不要选上, 中断和软中断就不会使用自己的栈, 而是使用被抢占任务的栈了.

所以栈不是中断不能sleep的原因.

zx_wing

原帖由 xiaozhaoz 于 2007-6-28 11:13 发表于 32楼  


中断sleep了, 由谁来唤醒?
在关中断的情况下, 不能sleep, 19楼已经描述了.
在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中 ...

>>在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的:
如果内核修改好了, handler中调用schedule_timeout_interrupt().的情况.
当然，如果你把handler用内核进程来实现，当然是可以睡眠和被调度的。这只是个实现问题。我这里的指的是linux下不能睡眠的原因。


>>中断都很紧急, 这不一定正确,
紧急是个相对概念，我认为中断都比进程紧急

xiaozhaoz

原帖由 zx_wing 于 2007-6-28 10:56 发表于 29楼  

此外，我想lz对上下文一词还有点误解。
上下文（context）表示当前cpu的状态，包括各种标志及寄存器的值。这里中断是运行在自己的上下文而不是进程的上下文。如果是运行在进程上下文的话，中断处理就不需要在 ...

nod, 在书里都是这样写的,
但是实际情况下比这个要复杂, 内核中光有上下文无法完成调度切换的工作,

所以在Linux Kernel中, 我一般将上下文指作可以协助Kernel完成调度的东西, 就是内核task, thread_info结构, + CPU寄存器.

[ 本帖最后由 xiaozhaoz 于 2007-6-28 11:32 编辑 ]

xiaozhaoz

原帖由 zx_wing 于 2007-6-28 11:25 发表于 35楼  

>>在中断handler中, 绝大部分都是开中断的, 这个时候为什么不能sleep? 时钟中断可以正常触发, 要不中断嵌套怎么实现? 当然由时钟中断的软中断来唤醒. 如我说到的:
如果内核修改好了, handler中调用sch ...

我想你还没有真正理解我的意思, 19楼的总结说得很清楚, 中断handler不能sleep,
不是因为没有"我说的上下文", 而是因为没有固定的上下文, 他会随机抢占当前任务, 使用当前任务的上下文作为调度单元. 既然有了调度单元, 他为什么不能sleep?

solaris12和我的想法差不多, 真正愿意那是调度问题和系统问题. 怎么解决这些问题, 就是19楼介绍的内核实时性瓶颈的问题.

augustusqing

在中断跟内核用的是同一个栈的情况下，如果系统允许某个handler中可以sleep，那么在不可预知的任何时候，任何一个内核线程/进程在执行的时候，恰好来了上面的中断并执行到了handler，则这个内核线程/进程就"中奖"了，就会sleep，而只要这个handler是在开中的情况下运行的，它是可以被其他线程/进程唤醒的，关键是系统中所有的线程/进程都有这个"中奖"机会，哈哈

这样理解对吗？

[ 本帖最后由 augustusqing 于 2007-6-28 11:45 编辑 ]

xiaozhaoz

原帖由 augustusqing 于 2007-6-28 11:41 发表于 38楼  
在中断跟内核用的是同一个栈的情况下，如果系统允许某个handler中可以sleep，那么在不可预知的任何时候，任何一个内核线程/进程在执行的时候，恰好来了上面的中断并执行到了handler，则这个内核线程/进程就&quo ...

对, 就是这个意思,
所以这种系统的不确定性就很大.  
而现在的中断除了不sleep, 不能preempt之外, 对任务的影响也想你说的那样"中奖"式的, 所以现在系统的实时性是无法保证的!!

解决这个问题的方法就是让handler只能在固定的上下文中sleep, 当然能不sleep最好不要sleep. 所以就有了将handler放到专门内核线程中处理的想法.

如果内核的实时性足够好, 那么handler线程的执行也可以得到保证.

zx_wing

原帖由 xiaozhaoz 于 2007-6-28 12:19 发表于 39楼  


对, 就是这个意思,
所以这种系统的不确定性就很大.  
而现在的中断除了不sleep, 不能preempt之外, 对任务的影响也想你说的那样"中奖"式的, 所以现在系统的实时性是无法保证的!!

解决这个问 ...

>>总结: 异步异常(中断)handler不是没有上下文, 而是没有固定的上下文,  如果使用被抢占的任务作为上下文, 一,自身的处理无法得到实时保障,导致系统不确定性, 二,任务受到影响.

linux是通用操作系统，并不是专门为嵌入式设计的实时操作系统，所以影响系统的实时性并不是中断不能睡眠的原因。
诚然，中断不像进程那样有固定的上下文，所以它在linux中不是调度器的调度单位，所以不能睡眠，因为睡眠、唤醒都是调度器的任务，你不被调度器调度，当然不能睡眠。如你所说，它是可以被实现成可睡眠的，但我这里讲述的是它在linux中不能睡眠的原因。如果我的理解还不对的话，请lz再用一句总结一下在linux中中断不能睡眠的原因。因为你文字比较多，我看的有点乱了。

[ 本帖最后由 zx_wing 于 2007-6-28 12:39 编辑 ]