linux进程调度发生的时机

所谓调度时机就是：什么时候会发生进程调度。在linux中，进程调度的函数是schedule()。但执行了schedule的代码也不一定发生进程调度，进程调度真正的发生还会和进程调度的政策有关（就是我们在操作系统里面常常看到的：先来先服务，时间片轮流等等）。如果执行了schedule 发现按照规则，还是自己应该运行自然也不会发生进程调度，但可以说明一点，只有在schedule出现的地方才有可能发生进程调度。那么在linux中那些地方会出现schedule呢？


我们先从代码中找，看有哪些代码出现了schedule,代码有2种：自己的，别人的（这么分应该可以吧），对于linux来说就是系统内核代码（说白了就是操作系统作者写的）和其它不是作者的程序员写的（用户程序）。下面分2这2种来看：


1. 是用户程序自己调度schedule，也许有人会觉得我的代码中能引用schedule吗？也许不行吧，但大家知道wait4我们是可以调用的，前面我们没有给出wait4的代码，但我们知道在执行了wait4效果是父进程被挂起，所谓的挂起就是不运行了，放弃了CPU，这里发生了进程调度是显而易见的，其实在代码中有如下几行：

current->state = TASK_INTERRUPIBLE;schedule();还有exit也有current->state = TASK_ZOMBIE; schedule();这2种发生了进程调度，从代码上也可以看出（状态被改成了睡眠和僵死，然后去调度可运行进程，当前进程自然不会再占有CPU运行了），从效果中也能看出。这说明用户程序自己可以执行进程调度。


2.系统代码中，除了前面我们说到的wait4和exit等外，还有一个地方会出现了schedule，就是中断返回代码里面出现了，这里出现了还加了限制条件，我们可以看看这个代码（所谓的中断返回代码，就是恢复中断现场的代码，每一个发生中断都会执行到的代码，无论是什么中断），这段代码是：

277 testl $(VM_MASK | 3),%eax  # return to VM86 mode or non-supervisor?
278 jne ret_with_reschedule
279 jmp restore_all

我们看到jne ret_with_reschedule在此之前还有一次条件判断，代码就不过多解释了，意思是：当中断发生在用户控件时候才会执行ret_with_reschedule，那么我们就看到，在中断返回到用户空间的前夕也是可能会发生进程调度的。

 

那么现在就是中断返回用户空间前夕，还有用户程序自愿放弃CPU，这2种情况会发生进程调度。

 

意义：1.从前面知道，程序在系统空间是不会发生进程调度的，这意味着只要是系统空间运行的代码不管多长都是原子操作（可以说是个缺陷，如果执行时间过长，那么其他进程将会严重滞后，不过还好，内核代码设计可以避免，但不能根治）。这就能解决了临界资源共享问题（单CPU情况下，多CPU依然要注意）。

 

2.我们常常说多进程并发执行，这种假象就是靠的就是进程调度，如果没有进程调度，那就不是并发了。我们知道进程只有在结束时候才会exit，还有wait4不是常常使用的，那么就意味着多进程并发不能靠进程自觉，只有靠中断，那么就证实了以前说的，时钟中断的重要性。