ucore操作系统lab6（理论部分）

一、实验流程

1、进程的正常生命周期如下：

进程首先在 cpu 初始化或者 sys_fork 的时候被创建，当为该进程分配了一个进程控制块之后，该进程进入 uninit态(在proc.c 中 alloc_proc)。
当进程完全完成初始化之后，该进程转为runnable态。
当到达调度点时，由调度器 sched_class 根据运行队列rq的内容来判断一个进程是否应该被运行，即把处于runnable态的进程转换成running状态，从而占用CPU执行。
running态的进程通过wait等系统调用被阻塞，进入sleeping态。
sleeping态的进程被wakeup变成runnable态的进程。
running态的进程主动 exit 变成zombie态，然后由其父进程完成对其资源的最后释放，子进程的进程控制块成为unused。
所有从runnable态变成其他状态的进程都要出运行队列，反之，被放入某个运行队列中。

2、调用进程调度函数schedule的位置和原因

编号	位置	原因
1	proc.c::do_exit	用户线程执行结束，主动放弃CPU控制权。
2	proc.c::do_wait	用户线程等待子进程结束，主动放弃CPU控制权。
3	proc.c::init_main	1. initproc内核线程等待所有用户进程结束，如果没有结束，就主动放弃CPU控制权; 2. initproc内核线程在所有用户进程结束后，让kswapd内核线程执行10次，用于回收空闲内存资源
4	proc.c::cpu_idle	idleproc内核线程的工作就是等待有处于就绪态的进程或线程，如果有就调用schedule函数
5	sync.h::lock	在获取锁的过程中，如果无法得到锁，则主动放弃CPU控制权
6	trap.c::trap	如果在当前进程在用户态被打断去，且当前进程控制块的成员变量need_resched设置为1，则当前线程会放弃CPU控制权

仔细分析上述位置，第1、2、5处的执行位置体现了由于获取某种资源一时等不到满足、进程要退出、进程要睡眠等原因而不得不主动放弃CPU。第3、4处的执行位置比较特殊，initproc内核线程等待用户进程结束而执行schedule函数；idle内核线程在没有进程处于就绪态时才执行，一旦有了就绪态的进程，它将执行schedule函数完成进程调度。这里只有第6处的位置比较特殊：

if (!in_kernel) {
    ……

    if (current->need_resched) {
        schedule();
    }
}

3、进程切换过程

假定有两个用户进程，在二者进行进程切换的过程中，具体的步骤如下：
首先在执行某进程A的用户代码时，出现了一个 trap (例如是一个外设产生的中断)，这个时候就会从进程A的用户态切换到内核态(过程(1))，并且保存好进程A的trapframe；当内核态处理中断时发现需要进行进程切换时，ucore要通过schedule函数选择下一个将占用CPU执行的进程（即进程B），然后会调用proc_run函数，proc_run函数进一步调用switch_to函数，切换到进程B的内核态(过程(2))，继续进程B上一次在内核态的操作，并通过iret指令，最终将执行权转交给进程B的用户空间(过程(3))。
当进程B由于某种原因发生中断之后(过程(4))，会从进程B的用户态切换到内核态，并且保存好进程B的trapframe；当内核态处理中断时发现需要进行进程切换时，即需要切换到进程A，ucore再次切换到进程A(过程(5))，会执行进程A上一次在内核调用schedule (具体还要跟踪到 switch_to 函数)函数返回后的下一行代码，这行代码当然还是在进程A的上一次中断处理流程中。最后当进程A的中断处理完毕的时候，执行权又会反交给进程A的用户代码(过程(6))。这就是在只有两个进程的情况下，进程切换间的大体流程。