OS：调度策略 - 技术栈

本文是自己在深入阅读Operating Systems Three Easy Pieces关于操作系统调度的知识点总结，后面会不断更新连续每一节，欢迎大家批评指正

0. overview

💡 本节介绍OS调度所采取的一些进程调度策略。

我们应该如何制定一个考虑调度策略的基本框架？关键假设是什么？哪些指标很重要？在最早的计算机系统中使用了哪些基本方法

周期周转时间（turnaround time .）：作业的周转时间定义为作业完成的时间减去作业到达系统的时间。

Tturnaround = Tcompletion − Tarrival
公平性：有些系统可能会优化性能，但代价是阻止一些作业运行，从而降低公平性
响应时间 response time：即程序开始运行的时间与到达的时间之差：

Tresponse = Tfirstrun − Tarrival

即先到的进程先运行，像排队一样，依次执行。这种策略实现简单，但是若运行时间长的进程运行在前面时，会导致排在后面运行时间短的进程出现挨饿（等太长，就好比你只需要花2分钟取100块钱，却要等前面那个人花2个小时去取100万，你愿意等嘛？ ）。

该思想是，将运行时间短的进程先运行（相当于按所需时间从小到大执行），这样就解决了FIFO的挨饿问题：

但现实很残酷！！假设A先到达，B，C在A到达后10分钟后才到，那么还是A先运行 ，即使B和C在A之后不久到达，他们仍然被迫等到A完成。

之前两种都是非抢占式的调度策略，即一个程序开始执行时，一直直到其结束（不会发生中断，被其他程序抢断执行）。

现在引入抢断执行的机制。

每当新作业进入系统时，STCF 调度程序都会确定哪个作业（包括新作业）的运行剩余时间最少，并安排该作业先执行。

如下图：A先到达时，先执行，但是当B,C到达时，发现他们的剩余执行时间都比A少，所以B，C抢占A的执行权，然后先执行

上述几种调度策略对周期时间优化 还可以，但是响应时间 的优化不是很好。例如，如果三个作业同时到达，则第三个作业必须等待前两个作业全部运行，然后才能仅计划一次。（就好比你坐在电脑前，输入运行程序，需要等待10分钟后，才能看到你的程序执行）

因此，我们留下了另一个问题：我们如何构建一个对响应时间敏感的调度程序？

基本思想很简单：RR 不是将作业运行到完成，而是针对一个时间段（有时称为计划量程）运行一个作业，然后切换到运行队列中的下一个作业。它会重复执行此操作，直到作业完成。

因此，RR 有时称为时间切片。请注意，时间片的长度必须是计时器中断周期的倍数。因此，如果计时器每 10 毫秒中断一次，则时间片可以是 10、20 或任何其他 10 毫秒的倍数。

RR即周期性的让每个程序运行相同的一段时间片时间，这样能让程序的响应时间最好，同时能够保证程序运行的公平性。

时间段的长度对于 RR 至关重要 。它越短，在响应时间指标下 RR 的性能就越好。但是，使时间片太短是有问题的：突然之间，上下文切换的成本将主导整体性能。

缺点：

同时RR会将某个程序运行的时间拓展（被划分到几个时间段执行），所以RR下程序的周期时间不会很好，甚至比前面两种方法要差。

所以要考虑系统的响应时间和程序运行周期时间，从而去选择不同的调度策略。

当一个程序执行I/O操作时，它被阻止等待 I/O 完成。如果将 I/O 发送到硬盘驱动器，则该过程可能会被阻止几毫秒或更长时间 ，具体取决于驱动器的当前 I/O 负载。因此，此时应该将另一个作业安排在 CPU 上。

调度程序还必须在 I/O 完成时做出决定。发生这种情况时，将引发中断，操作系统将运行发出 I/O 的进程，并将发出 I/O 的进程从"阻止"移回就绪状态。当然，它甚至可以决定在此时运行作业。

💡 事实上，OS很难提前知道每个程序运行的时间，因此，如果没有这样的先验知识，我们如何才能建立一种像SJF / STCF这样的方法呢？