<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
进程的调度
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } A:link { so-language: zxx } -->
linux系统中,一个进程有5种可能状态,在sched.c第19行处定义了状态的标识:
#define TASK_RUNNING 0 // 正在运行或可被运行状态
#define TASK_INTERRUPTIBLE 1 // 可被中断睡眠状态
#define TASK_UNINTERRUPTIBLE 2 // 不可中断睡眠状态
#define TASK_ZOMBIE 3 // 僵死状态
#define TASK_STOPPED 4 // 停止状态
各种状态的转换图如下:
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
就绪态和运行态之间的转换
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
当前占用CPU的进程调只有用了schedule()函数后,才可能会从运行态进入就绪态。Schedule()函数按照一定的选择策略选中处于TASK_RUNNING态(包括用户运行态,内核运行态和就绪态)的某个进程,然后切换到该进程去执行。这时被选中的进程进入运行态,开始使用CPU资源。被选中的进程可能是刚刚调用schedule()函数的进程,也可能是其他进程。
schedule()函数在3种情况下会被调用
用户态时发生了时钟中断;
系统调用时相应的sys_XXXX函数返回后;
睡眠函数内;
第一种情况发生在用户态。当时钟中断产生时,如果进程运行在用户态时并且时间片用完,中断处理函数do_timer()会调用schedule()函数,这相当于用户态的运行被抢断了。如果进程处在内核态时发生时钟中断,do_timer()不会调用schedule()函数,也就是内核态是不能被抢断的。当一个进程运行在内核态,除非它自愿调用schedule()函数而放弃CPU的使用权,它将永远占用CPU。由于schedule()不是系统调用,用户程序不能调用,所以在时钟中断中调用schedule()是必要的,这样保证用户态的程序不会独占CPU。
第二种情况就是为了对付运行在内核态的进程。应用程序一般通过系统调用进入内核态,因此linux 0.11在系统调用处理函数(sys_XXXX())结束后,int 0x80处理函数会检查当前进程的时间片和状态,如果时间片用完或状态不是TASK_RUNNING,会调用schedule()函数。这时相当于内核态进程主动放弃对对CPU的占用。由此可见,如果某个系统调用处理函数或者中断异常处理函数永远不退出,比如进入死循环或者等待其他资源,整个系统死锁,任何进程都无法运行。
比较前两种情况,我们看到linux有保证用户态的程序不独占CPU的机制,却不能保证内核态程序不独占CPU。这也反映了系统级别开发和用户级别开发的不同之处。系统程序员需要考虑更多的问题。
第三种情况在下面一节运行态(包括就绪态)和睡眠态之间的转换中讨论。当进程等待的资源还不可用时,它进入睡眠态,并且调用schedule()让出CPU。
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
switch_to() (sched.h 第173行)
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
schedule()(sched.c 第104行)
<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } -->
当前进程只有调用了schedule()后才能发生进程切换,因此当进程再次被选中执行后,都是从switch_to()中ljmp后一条语句开始执行,即从"cmpl %%ecx,last_task_used_math/n/t"语句继续,这时进程位于内核态。因此进程从就绪态进入的都是内核运行态。但有一个例外,进程产生后第一次被调度执行。
fork()产生的子进程会把父进程原cs、原eip当作初始的cs、eip,所以子进程刚刚创建时处于用户态。第一次进程被调度时,从就绪态进入的是用户运行态。以后进入的都是内核运行态。