免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
1234
最近访问板块 发新帖
楼主: cskyrain

中断处理程序为什么不能阻塞休眠???以前真没认真思考过! [复制链接]

论坛徽章:
0
发表于 2009-11-25 17:56 |显示全部楼层

回复 #30 fox144215 的帖子

晕倒…… 既然你知道,25楼的结论怎么来的?

你都知道栈有两层,顶上一层是用户态的信息,第二层是内核态被中断时的信息。 难道中断上下文block以后这个信息就变了?

论坛徽章:
0
发表于 2009-11-25 20:40 |显示全部楼层
我服了你了,考虑这种情况:如果系统调用返回了,中断还在阻塞呢?

论坛徽章:
0
发表于 2009-11-25 22:11 |显示全部楼层

回复 #32 fox144215 的帖子

呵呵, 我更服了你了.
中断怎么阻塞? 中断上下文没有task_struct, 不能被调度, 怎么被阻塞?
很显然, 中断上下文的阻塞将导致被中断的current进程被阻塞. 既然, current阻塞了, 又怎么从系统调用中返回?

论坛徽章:
0
发表于 2009-11-26 13:05 |显示全部楼层
中断上下文没有task_struct,没有内核栈如何保存和恢复现场呢,另外,current不可以被其他模块唤醒?

论坛徽章:
0
发表于 2009-11-26 13:07 |显示全部楼层
算了,这个话题不讨论了,你认为是就是吧

论坛徽章:
0
发表于 2009-11-26 19:22 |显示全部楼层

http://www.china-pub.com/301691上的解释

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

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


摘自   http://www.china-pub.com/301691

[ 本帖最后由 lucasman 于 2009-11-26 19:25 编辑 ]

论坛徽章:
59
2015年亚洲杯之约旦
日期:2015-01-27 21:27:392015年亚洲杯之日本
日期:2015-02-06 22:09:41拜羊年徽章
日期:2015-03-03 16:15:432015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:50:282015元宵节徽章
日期:2015-03-06 15:50:392015年亚洲杯之阿联酋
日期:2015-03-19 17:39:302015年亚洲杯之中国
日期:2015-03-23 18:52:23巳蛇
日期:2014-12-14 22:44:03双子座
日期:2014-12-10 21:39:16处女座
日期:2014-12-02 08:03:17天蝎座
日期:2014-07-21 19:08:47
发表于 2009-11-28 20:31 |显示全部楼层
原帖由 snail_314 于 2009-11-24 22:35 发表
我的想法是,一个进程能失去处理器控制,只有两种情况,一种是“被”剥夺,就是在用户态时,tick到了,按照等时调度策略,这个进程需要让出处理器资源了。第二种就是该进程“主动”让出处理器资源。而假如在中断 ...


中断时Sleep会发生严重的同步问题,想一想:

中断发生--》进入中断--》Sleep--》执行其它程序--》调度回来继续中断处理过程--》结束
                                                              ^
                                                              |
                                                              |
                                          此下再次发生相同的中断,重复以上过程此中断将会Access相同的内核数据。这可以引起内核Panic

当然,你说的好个也是原因之一,也就是公平问题

论坛徽章:
0
发表于 2009-11-29 11:18 |显示全部楼层
An irq is not a context but merely a temporary execution to
    be concluded asap.    是机制问题而不是策略问题。

论坛徽章:
59
2015年亚洲杯之约旦
日期:2015-01-27 21:27:392015年亚洲杯之日本
日期:2015-02-06 22:09:41拜羊年徽章
日期:2015-03-03 16:15:432015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:50:282015元宵节徽章
日期:2015-03-06 15:50:392015年亚洲杯之阿联酋
日期:2015-03-19 17:39:302015年亚洲杯之中国
日期:2015-03-23 18:52:23巳蛇
日期:2014-12-14 22:44:03双子座
日期:2014-12-10 21:39:16处女座
日期:2014-12-02 08:03:17天蝎座
日期:2014-07-21 19:08:47
发表于 2009-11-30 19:53 |显示全部楼层
原帖由 kouu 于 2009-11-25 22:11 发表
呵呵, 我更服了你了.
中断怎么阻塞? 中断上下文没有task_struct, 不能被调度, 怎么被阻塞?
很显然, 中断上下文的阻塞将导致被中断的current进程被阻塞. 既然, current阻塞了, 又怎么从系统调用中返回?


是可以被“Block”的,如果你一定要这样设计的话。中断上下文可以保存在当前进程的TSS中。

不过,此时中断将可能被无限搁置。因为人家可能挂起这个进程,更糟糕的是,有人要强行结束这个进程。
如果中断可以Block,必须要考虑这些问题。不过,X86的机器可以让中断在一个系统上下文中执行(有中断门和中断段Descriptor的支援,当然,出于通用目的,OS设计者很可能不使用这个特性)还有一个问题就是我上贴所说的原因。总之,将中断设计可以被Block(但可以被抢先)会有很多问题。系统会变得很没有效率。
反正在没有更好的系统模型以前。记住Int是不能Block的就行了。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP