中断上下文中不能睡眠，那系统调用代表当前进程为什么能睡眠而发生进程切换？

ilogo1

系统调用是属于软中断，系统调用处理程序调用了系统调用例程，为什么允许系统调用被阻塞。系统调用被阻塞，那么系统调用处理程序也就会被阻塞，然而软中断处于中断上下文，不允许睡眠，这 不是矛盾？

samon_fu

信号是一种软中断机制，不是系统调用

ilogo1

信号？有点凌乱回复 2# samon_fu


   

lrita

中断中要是睡眠了，就没人能叫醒它了，就直接睡死了。

lenky0401

这个说起来有点多,一一来看:
1,中断要根据前后文来说,一般说中断上下文中不能睡眠,这个中断是指硬件事件发生,触发CPU停止当前活动转而去处理硬件请求.
2,根据硬件请求响应处理逻辑的实时紧要与否,将整个中断处理过程分为上半部和下半部.
3,上半部也就是所谓的硬中断处理逻辑,其要求cpu在收到硬件请求后必须马上处理的事情,比如网卡收到数据包了,把数据包从网卡缓存拷贝到主存(可以由DMA完成,但寄存器的修改以及资源设定还是要由cpu去做)的逻辑就需要cpu立即去做,不做的话,网络新来的数据包就可能丢失.所以这些紧要操作逻辑为硬中断处理.
4,下半部有很多种机制,其中就包括软中断,还有tasklet,workqueue等,软中断只是其中的一种,由于历史的原因,有时候是混淆称呼下半部和软中断的.
5,软中断处理的逻辑并不那么严格要求及时,比如对网络数据包的处理,因为逻辑复杂,不适合放到硬中断里去做,因为要尽量保证硬中断短小精悍.
6,linux调度是以进程(或者说线程)来的,即做调度是不同进程上下文的切换.
7,而可以看到软中断逻辑不属于任何进程,所以才不能睡眠,因为一旦睡眠,cpu切换出去,就切不回来了(和6一起理解).并不是说无法做到在软/硬中断睡眠,只是目前Linux的实现就是这样的,不允许你这么做,要是这么做了,你就等死.

8,系统调用是属于软中断?难道是指int 0x80?这个不知道是什么概念,但肯定不是与上面的软中断同一个意思.给你两个链接:
http://lenky.info/2013/02/04/32% ... %E8%B0%83%E7%94%A8/
http://lenky.info/2013/02/04/64% ... %E8%B0%83%E7%94%A8/

ilogo1

系统调用通过80中断进入内核，那么就有一内核控制路径代表当前进程在内核态运行，那么针对80中断有一个中断处理程序吧。在这个中断处理程序里边调用了对应的系统调用吧。那么系统调用的阻塞会不会导致中断处理程序的的睡眠，也就是引起这一内核控制路径的睡眠，但是这条内核控制路径不是处于中断处理中么？怎么能睡眠，所以我有点糊涂。应该是没分清处一些问题回复 5# lenky0401


   

lenky0401

通过int 0x80只是实现系统调用的一种方式，而且是最古老的一种方式。应用程序利用int指令进行主动陷入内核，更应该称之为软件中断，这与前面提到的下半部的软中断不是一个概念。应用程序执行系统调用进入到内核后，内核处于进程上下文，是可以阻塞/睡眠的，是中断上下文不能睡眠。

lenky0401

如果当前是进程上下文，那么表示如果切换出去，还有机会切换回来，因为当前有进程这个实体作为被调度的代表。
如果当前是中断上下文，那么表示如果切换出去，就没有机会切换回来了。

zylthinking

在开中断下，没有中断中不能睡眠的铁律， 只有中断中不能睡眠的选择。 若是单核并且关中断了， 确实不允许睡眠因为时钟中断禁止的结果就是调度停止， 除此之外没有不允许的绝对理由， 只因为若允许睡眠， 不免对被调度出去的进程不大公平。

yangphox

楼主让我为你终结此问题，回答此问题需要逆向思维。

对，中断中不能睡眠。但这只是“设计结果”，关键是要理解“设计原因”是什么。

先说“设计结果”：
进程之所以能够睡眠，因为内核提供了一个机制——在进程睡眠时，将进程的所有必要信息保存起来，以备恢复之用。
中断之所以不能够睡眠，因为内核没有为它提供这样一个机制——比如中断没有struct task_struct。

那么“设计原因”是什么呢？
中断之所以被设计出来，就是为了“快速响应”！
内核开发者是这样想的：我要设计一种东西可以快速响应，当然它就没必要睡眠啦。设计睡眠和恢复机制挺麻烦的，我就不为它搞这些冗余的功能了:）对了给这种东西起名叫中断吧！

什么？你说你需要一种东西既要快速响应、又要可以睡眠？
亲，你知道自己到底再说什么吗？世上可没有　即方又圆　的东东。

只是需要睡眠？乖乖用我设计的“进程”神器吧！