实验执行流程概述

在实验五,创建了用户进程,并让它们正确运行。这中间也实现了 FIFO 调度策略。可通过阅读实验五下的 kern/schedule/sched.c 的 schedule 函数的实现来了解其 FIFO 调度策略。与实验五相比,实验六专门需要针对处理器调度框架和各种算法进行设计与实现,为此对 ucore 的调度部分进行了适当的修改,使得 kern/schedule/sched.c 只实现调度器框架,而不再涉及具体的调度算法实现。而调度算法在单独的文件(default_sched.[ch])中实现。

除此之外,实验中还涉及了 idle 进程的概念。当 cpu 没有进程可以执行的时候,系统应该如何工作?在实验五的 scheduler 实现中,ucore 内核不断的遍历进程池,直到找到第一个 runnable 状态的 process,调用并执行它。也就是说,当系统没有进程可以执行的时候,它会把所有 cpu 时间用在搜索进程池,以实现 idle 的目的。但是这样的设计不被大多数操作系统所采用,原因在于它将进程调度和 idle 进程两种不同的概念混在了一起,而且,当调度器比较复杂时,schedule 函数本身也会比较复杂,这样的设计结构很不清晰而且难免会出现错误。所以在此次实验中,ucore 建立了一个单独的进程(kern/process/proc.c 中的 idleproc)作为 cpu 空闲时的 idle 进程,这个程序是通常一个死循环。你需要了解这个程序的实现。

接下来可看看实验六的大致执行过程,在 init.c 中的 kern_init 函数增加了对 sched_init 函数的调用。sched_init 函数主要完成了对实现特定调度算法的调度类(sched_class)的绑定,使得 ucore 在后续的执行中,能够通过调度框架找到实现特定调度算法的调度类并完成进程调度相关工作。为了更好地理解实验六整个运行过程,这里需要关注的重点问题包括:

  1. 何时或何事件发生后需要调度?
  2. 何时或何事件发生后需要调整实现调度算法所涉及的参数?
  3. 如果基于调度框架设计具体的调度算法?
  4. 如果灵活应用链表等数据结构管理进程调度?

大家可带着这些问题进一步阅读后续的内容。

results matching ""

    No results matching ""