0 前言

接上一篇文章：进程调度（2b）：STCF（最短完成时间优先） 算法 原理与实践

1 前提铺垫

除了与上一篇相同的，这里介绍新的基础知识。

1.1 三种类型的程序

• 计算密集型（CPU导向）
• 输入输出密集型（I/O导向）
• 中间型

所谓计算密集型程序，就是大量时间都在占用CPU做运算，例如科学计算。而输入输出密集型程序，则大量时间都在进行输入输出，你很熟悉它，例如人机交互，我们每时每刻都在用计算机干这个事情。中间型就是二者都有，占比差不多。

那么介绍这个有什么用？

当我们的目标不同的时候，性能指标的评价标准也不同，对于计算密集型程序，我们可能更关注它的Turnaround Time，而对于（交互型的）输入输出密集型程序，我们可能更关注它的Response Time。后续我们会对算法进行性能评价，设计目标很重要不是吗？

1.2 响应时间（Response Time）

这是一个新的性能指标。

Response Time: the time a job spends waiting after arrival before first running.

所谓响应时间，就是从任务到达后，到第一次被执行的等待时间。这个概念在分时操作系统诞生后变得尤为重要，用户是“独占”计算机的，并且是交互式界面，所以对用户来说，响应时间非常重要，用户必须等待很短的时间就能看到一部分结果。

试想一个场景，你敲击了键盘的字母Z，然后在10s之后，才看见屏幕显示了Z……这真的令人抓狂不是吗？

我们需要做的，就是让用户快速看到自己的成果，此时，并不需要将程序执行完成，将程序运行一点点先给用户显示出来，这对于用户来说是很棒的！

那么应该如何做到这一点？答案就是充分使用上下文切换。还记得上一篇我们的抢占式调度吗？它第一次打破了进程顺序执行，实现了简易的进程（上下文）切换，现在，我们要充分利用上下文切换，来让用户因为快速响应而得到满足了！

但是要警惕！没有必要太快！上下文切换也是需要系统开销的，它的占比应该尽可能小，我们后续会深入谈。现在，你只需要知道，响应时间是1s还是0.1s，对用户来说是没有什么区别的，因此我们选择1s即可，这样将上下文切换的数量降低了10倍。

1.3 上下文切换（Context Switch）

好吧……上面说了这么多上下文切换，它到底是个啥？第一篇我提到了底层机制 + 上层策略，当时只是提了一句，现在，我们再进一步说一说。

• 底层机制：上下文切换
• 上层策略：FIFO，SJF，STCF，RR……

在解释这个之前，我们先来谈谈刀吧。对的，就是刀！

你知道的，刀可以削水果，可以切菜，也可以雕刻……但是归根结底，都是在刀足够锋利的前提下，这些事情才能完成，我们分析一下：

• 底层机制：刀足够锋利
• 上层策略：削水果，切菜，雕刻……

也就是说，在刀锋利这个底层机制满足的前提下，我们才能切菜削水果。

好吧现在我们回来，对于进程调度算法而言，也是一样的，我们在能够实现上下文切换（进程切换）的前提下，才能使用各种各样的方法进行进程调度。

你要问我Context Switch是什么样的？我来画张图。

我想你明白了，只是切换而已。如果说更关键的，可能是

• 保存现场和恢复现场是如何实现的？
• 上下文切换的系统开销是多少?

我们先不回答这个问题，你只需要知道，每次上下文切换的时间 / 每个时间片的时间 这个比例应该小一点！（时间片下面就会谈）

2 RR原理

RR（Round - Robin）轮转，轮转算法下，多个进程不再是顺序执行，而是切换式执行，这样对于交互式程序来说，用户就能快速感受到自己执行的操作得到了响应，响应时间短。

2.1 算法

举个例子

• A：20s
• B：20s
• C：20s

在顺序执行下，上述3个进程按照A、B、C的顺序依次执行，如下图：

这样一来，响应时间分别是

• A：0s
• B：20s
• C：40s

对于执行C程序的用户来说，他可能会非常崩溃……响应太慢总是让人发疯的，不是吗？

如果我们采用轮转算法，假定一个时间片为10s，结果就不一样了，所谓时间片，就是指某进程在CPU执行10s，就要被中断，然后让其他进程执行（也就是每隔10s就进行上下文切换）。

我们看看会发生什么：

这样一来，响应时间分别为

• A：0s
• B：10s
• C：20s

响应时间缩短很多了，但是好像还是慢，如果时间片设置为1s呢？响应时间就是0s，1s和2s，这就很棒了！

2.1.1 思考1：时间片可以无限小下去吗？

我们的用户当然想要更快获得响应，但是对于用户来说，1s和0.1s可能没什么差别，所以我们完全可以选择1s，那么，选择更大值的理由是什么？不选0.1s的理由是什么?

答案就是切换上下文需要系统开销，切换上下文的时候，要保存当前程序的状态，我们切换越频繁，系统的额外开销就越多，要之前，顺序执行的时候我们根本不需要这样做，所以，切换上下文带来的开销应该尽可能小一点。

例如，时间片是10ms，切换上下文需要1ms，那么我们需要浪费10%的时间去切换上下文，如果时间片是100ms，就占1%，这还可以接受，物极必反的道理就在于此了。

• 扩展：可以思考下奔腾4的失败，CPU的流水线深度越深性能就越好吗？奔腾4使用了31级流水线，性能反而下降了，现代CPU的流水线也不过十几级，例如i7是14级。
• 推荐阅读：面向流水线的指令设计：奔腾4是怎么失败的？

所以说，时间片是不能无限小下去，它的占比应该小一点，小到什么程度那就与具体需求和实现有关了。

假设切换上下文1s，时间片10s，上面的例子就成了这样：

相关分析请读者自行完成。

2.1.2 思考2：时间片的设置可以是任意的吗？

对于上下文切换这个底层机制的实现，是由软硬件协同完成的，这里有一个重要的概念时钟中断，时钟每隔一段时间，就会中断程序，把控制权从正在执行的程序交还给OS。

因此说，我们的时间片应该是时钟中断周期的整倍数，这样，我们就能保证每个时间片在执行的时候不会被时钟中断所打断（被程序本身的系统调用打断就是另一回事了……）

2.2 缺点：大锅饭式分配 & 增长的周转时间

RR算法下，对所有就绪进程都是一视同仁的，不管你是谁，都会被执行，切断，切换，恢复，再执行，就像大锅饭一样，不管你干活多少，吃的饭都一样。

但是我们知道，不同的程序，重要程度和紧急程度是不一样的，但是RR全忽略了，这显然不合理。

另外，响应时间确实是改进了，但是此时程序周转时间表现不佳，这是显而易见的。

因此我们的算法仍需要进一步改进。

3 RR实践

我们来进行几个模拟，体会上一小节的几个观点吧。

我们先试一下SJF，3个进程都是100s，同时到达

./scheduler.py -p SJF -l 100,100,100 -c

得到的结果是

Average -- Response: 100.00  Turnaround 200.00  Wait 100.00

再试试RR，3进程都是100s，时间片是1s，忽略上下文切换时间

./scheduler.py -p RR -q 1 -l 100,100,100 -c

得到的结果是

Average -- Response: 1.00  Turnaround 299.00  Wait 199.00

你可以充分体会到，SJF的响应时间是RR是100倍，RR的周转时间是SJF是1.5倍，而在更极端的情况下，差距可能会更大。

4 核心思想

目前我们接触到的都是计算密集型程序，而且是100%占用CPU，我们关注了两大性能指标，周转时间和响应时间。

• 关注周转时间的算法：FIFO，SJF和STCF
• 关注响应时间的算法：RR

目前来说，我们还

• 没有同时兼顾周转时间和响应时间的算法
• 没有考虑包含输入输出的程序的算法

这也是接下来我们要改进的。

5 预告：进程调度（4）：I/O、不可预测的运行时间

接下来，我们初步为程序引入I/O，并且谈谈最初的一个假设运行时间已知是否现实。

链接：进程调度（4）：I/O、不可预测的运行时间