面试必备操作系统之进程调度算法（非常全面）

今天药忘吃喽~ 2022-10-13 01:57 226阅读 0赞

### 文章目录 ###

*   *  背景
     *  衡量指标
     *  调度算法
     *   *  先进先出（FIFO）
         *  最短任务优先（SJF）
         *  最短完成时间优先（STCF）
         *   *  新衡量指标：响应时间
         *  轮转（Round-Robin，RR）
     *  去掉假设没有IO操作
     *  参考

## 背景 ##

假设在单核cpu上如何让进程运行更高效呢？在io等待的时候是否可以执行其他进程来达到高效的调度呢，在单核cpu中有程序并行运行的感觉，要做到这些就要依赖操作系统的调度算法。

## 衡量指标 ##

在调度算法中，我们要选择哪一个调度算法，那个调度算法性能最高，评价标准是什么？一般我们都是周转时间来评论：

*  T周转时间= T完成时间−T到达时间

如果假设所有的任务在同一时间到达，那么`T到达时间= 0`，因此`T周转时间= T完成时间`

> 但是有时候一些调度算法为了性能会丢失公平性，也就是可能有些任务始终无法得到调度，也就是产生了饥饿，具体我们来看看下面不同的调度算法

## 调度算法 ##

### 先进先出（FIFO） ###

这是最简单也是最基础的调度算法

*  定义：哪个任务先来就先执行哪个
 *  特点：
    
     *  实现简单
 *  举例说明：  
    假设 现在有A、B、C三个任务在相同的时间到达系统(T到达时间= 0)。但是A比B早一点点，然后B比C早到达一点点。每个工作运行10s。这些工作的平均周转时间（average turnaround time）是多少呢？

这里我们先作出几个假设：

1.  任务同时到达
2.  任务没有IO操作
3.  任务时间是已知的

> 随着研究的深入我们会慢慢放开这些假设  
> ![在这里插入图片描述][20210705224147469.png]

平均周转时间 = （10 + 20 + 30）/ 3 = 20

但是如果这里我们假设A运行的时间需要100s，其他条件不变，那么  
平均周转时间 = （100 + 110 + 120）/ 3 = 110  
![在这里插入图片描述][20210705224320562.png]  
可以看到平均周转时间非常高，这样来看FIFO就不那么好了。  
这种现象通常被称为护航效应（convoy effect）。一些耗时较少的潜在资源消费者被排在重量级的资源消费者之后。就像你在排队买东西，明明你只要1秒钟就可以结完账，而前面的一个人买了一大堆东西，需要100s，而你就需要等待他100s。  
所以这种调调算法缺点很明细，那么我们试试让最短的任务最先调度，是不是就解决了上面的问题呢？

### 最短任务优先（SJF） ###

*  定义：先运行最短的任务，然后是次短的任务

我们仍然使用上面的例子然后使用最短任务优先（SJF）调度算法来看看  
![在这里插入图片描述][20210705224747231.png]  
平均周转时间 = （10 + 20 + 120）/3= 50

可以看到提升是非常明显的。看样子最短任务优先（SJF）似乎是我们理想的调度算法了，但是这是在我们假设任务同时到达的前提先发生的，现实往往并非如此，如果A、B、C任务不是同时到达呢。  
这里我们再假设A在t = 0时到达，需要运行100s。而B和C在t = 10到达，且各需要运行10s  
![在这里插入图片描述][20210705225021907.png]  
从图中可以看出，即使B和C在A之后不久到达，它们仍然被迫等到A完成，从而遭遇同样的护航问题。这3项工作的平均周转时间为  
103.33s =（100+（110−10）+（120−10））/3

> 遇到这个问题我们要如何设计一款更好的调度算法呢，我们可能想到了，就是在B、C任务来临时，如果他们的执行时间相对A来说较短，就可以停下A去执行B、C，这种调度方式就是抢占式的，现代操作系统基本都是使用的抢占式调度算法。

### 最短完成时间优先（STCF） ###

在了解这个算法之前我们先聊聊两个定义

*  时钟中断：如果任务没有执行IO操作主动放弃使用CPU，即使是操作系统也无法获取到CPU的执行权，所以就有时钟设备可以编程为每隔几毫秒产生一次中断。产生中断时，当前正在运行的进程停止，操作系统中预先配置的中断处理程序（interrupthandler）会运行。此时，操作系统重新获得CPU的控制权。（基于硬件层面获取CPU控制权）
 *  上下文切换：操作系统要为当前正在执行的进程保存一些寄存器的值（例如，到它的内核栈），并为即将执行的进程恢复一些寄存器的值（从它的内核栈）。
 *  定义: 每当新工作进入系统时，它就会确定剩余工作和新工作中，谁的剩余时间最少，然后调度该工作

![在这里插入图片描述][20210705225749900.png]  
基于上面的例子我们再来看看这种调度算法的平均周转时间为  
50s。

#### 新衡量指标：响应时间 ####

这里看似我们似乎找到了最优的调度算法  
但是如果我们再加入一个考察指标呢：响应时间  
如果我们知道任务长度，而且任务只使用CPU（即假设没有IO操作），而我们唯一的衡量是周转时间，STCF会是一个很好的策略。事实上，对于许多早期批处理系统，这些类型的调度算法有一定的意义。然而，引入分时系统改变了这一切。现在，用户将会坐在终端前面，同时也要求系统的交互性好。因此，一个新的度量标准诞生了：响应时间（response time）  
T响应时间= T首次运行−T到达时间  
如果我们有上面的调度（A在时间0到达，B和C在时间10达到），每个作业的响应时间如下：作业A为0，B为0，C为10（平均：3.33）

如果3个工作同时到达，第三个工作必须等待前两个工作全部运行后才能运行(一些IO操作)。这种方法虽然有很好的周转时间，但对于响应时间和交互性是相当糟糕的。假设你在终端前输入，不得不等待10s才能看到系统的回应，只是因为其他一些工作已经在你之前被调度：你肯定不太开心

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

### 轮转（Round-Robin，RR） ###

*  定义：RR在一个时间片（time slice，有时称为调度量子，scheduling quantum）内运行一个工作，然后切换到运行队列中的下一个任务，而不是运行一个任务直到结束。它反复执行，直到所有任务完成

> 因此，RR有时被称为时间切片（time-slicing）。因此，如果时钟中断是每10ms中断一次，则时间片可以是10ms、20ms或10ms的任何其他倍数

我们来看一个例子:  
假设3个任务A、B和C在系统中同时到达，并且它们都希望运行5s  
我们看看 最短任务优先（SJF）和 RR的一个对比  
![在这里插入图片描述][20210705230649278.png]  
RR的平均响应时间是：（0 + 1 + 2）/3 = 1 周转时间：（13+14+15）/ 3 = 14  
SJF 算法平均响应时间是：（0 + 5+ 10）/ 3 = 5

这里可以看到时间片长度对于RR是至关重要的。越短，RR在响应时间上表现越好。然而，时间片太短是有问题的：突然上下文切换的成本将影响整体性能。因此，系统设计者需要权衡时间片的长度，使其足够长，以便摊销（amortize）上下文切换成本，而又不会使系统不及时响应

*  摊销技术（amortization）:通过减少成本的频度（即执行较少次的操作），系统的总成本就会降低。例如，如果时间片设置为10ms，并且上下文切换时间为1ms，那么浪费大约10%的时间用于上下文切换。如果要摊销这个成本，可以把时间片增加到100ms。在这种情况下，不到1%的时间用于上下文切换，因此时间片带来的成本就被摊销了

> 上下文切换的成本不仅仅来自保存和恢复少量寄存器的操作系统操作。程序运行时，它们在CPU高速缓存、TLB、分支预测器和其他片上硬件中建立了大量的状态。切换到另一个工作会导致此状态被刷新，且与当前运行的作业相关的新状态被引入，这可能导致显著的性能成本

上面的问题说完，我们可以看到RR我给出的另一个指标周转时间14,如果用之前的评判标准来说RR似乎是最差的调度算法。

所以看到似乎并没有完美的算法，这上面的算法似乎都有一个显著的特点：公平或非公平，即是否抢占式

*  如果是非公平的，响应时间会很短，但是要以周转时间为代价
 *  如果是公平的，周转时间会很短，但是要以响应时间作为代价

## 去掉假设没有IO操作 ##

待更新…

## 参考 ##

*  操作系统导论

[20210705224147469.png]: /images/20221005/6e69da114ac14d159c2e7662d199c322.png
[20210705224320562.png]: /images/20221005/43a33d90a50d4bab8358adf80d4378cc.png
[20210705224747231.png]: /images/20221005/17686bea080a4cb79c25fd26723e747d.png
[20210705225021907.png]: /images/20221005/09d4a134440c440da9ece7e6acbbf080.png
[20210705225749900.png]: /images/20221005/b7ce08cd2f794bd1b017be70ef13ffaf.png
[20210705230649278.png]: /images/20221005/f4063fe43420451289db4f077669e5f5.png