【8. 调度算法】

小呆鸟_coding

已于 2022-09-04 21:09:46 修改

阅读量532

点赞数 3

分类专栏：操作系统文章标签： java 开发语言 linux ubuntu windows

于 2022-08-23 16:49:33 首次发布

本文链接：https://blog.csdn.net/weixin_45043334/article/details/126451433

版权

操作系统专栏收录该内容

15 篇文章 2 订阅

订阅专栏

在这里插入图片描述

🎉作者简介:👓 $\textcolor{orange}{博主在读机器人研究生，目前研一。对计算机后端感兴趣，喜欢c++,go,python,目前熟悉c++，go语言，数据库，网络编程，了解分布式等相关内容}$
📃 $\textcolor{gray}{个人主页：}$ 小呆鸟_coding
🔎 $\textcolor{gray}{支持:}$ $\textcolor{green}{如果觉得博主的文章还不错或者您用得到的话，可以免费的关注一下博主，如果三连收藏支持就更好啦}$ 👍 $\textcolor{green}{就是给予我最大的支持！}$ 🎁
💛本文摘要💛

本专栏主要是讲解操作系统的相关知识本文主要讲解调度算法

文章目录

🌑调度算法
🌗1. 背景
🌗2. 调度原则
🌔2.1 概述
🌔2.2 调度策略

🌗3. 调度算法
🌔3.1 FCFS (先来先服务)
🌔3.2 SPN(不可抢占短作业优先) SRT (可抢占短作业优先)
🌔3.3 HRRN(最高响应比优先)
🌔3.4 Round Robin(轮循)
🌔3.5 Multilevel Feedback Queues(多级反馈队列)
🌔3.6 Fair Share Scheduling(公平共享调度)

🌗4. 实时调度（前面是通用调度）
🌔4.1 概述
🌔4.2 实时系统
🌔4.3 速率单调调度(RM)
🌔4.4 最早期限调度(EDF)

🌗5. 多处理器调度
🌗6. 优先级反转

清华操作系统系列文章：可面试可复习
1. 操作系统—概述
 2. 操作系统—中断、异常、系统调用
 3. 操作系统—物理内存管理
 4. 操作系统—非连续内存分配
 5. 虚拟内存管理
 6. 操作系统—虚拟内存管理技术页面置换算法
 7. 进程管理
 8. 调度算法
 9. 同步与互斥
 10. 信号量和管程
 11. 死锁和进程通信
 12. 文件系统管理

🌑调度算法

背景
- CPU调度
- CPU调度时间
调度准则
调度算法
实时调度
多处理器调度
优先级反转

🌗1. 背景

上下文切换

切换CPU的当前任务, 从一个进程/线程到另一个
保存当前进程/线程在PCB/TCB中的执行上下文(CPU状态)
读取下一个进程/线程的上下文

CPU调度（什么时候切，根据什么原则切）

从就绪队列中挑选一个进程/线程作为CPU将要运行的下一个进程/线程
调度程序: 挑选进程/线程的内核函数(通过一些调度策略)
什么时候进行调度?

从一个状态到另一个状态变化的时候，会触发一次调度,特别是和运行相关的状态变化

在这里插入图片描述
用户态运行调度

调度需要考虑俩种情况，大部分调度的是应用程序，对于应用程序而言，它运行是在用户态的进程形式存在的

内核运行调度

内核运行调度程序的条件(满足一条即可)

一个进程从运行状态切换到等待状态
一个进程被终结

不可抢占

调度程序必须等待事件结束

可以抢占

调度程序在中断被相应后执行
当前的进程从运行切换到就绪, 或者一个进程从等待切换到就绪
当前运行的进程可以被换出

🌗2. 调度原则

🌔2.1 概述

调度策略
程序执行模型
比较调度算法的准则
吞吐量VS延迟
公平的目标

🌔2.2 调度策略

调度策略

人们通常都需要"更快"的服务
什么是更快?

传输文件时的高带宽
玩游戏时的低延迟
这两个因素是独立的

和水管类比

低延迟: 喝水的时候想要一打开水龙头水就流出来
高带宽: 给游泳池充水时希望从水龙头里同时流出大量的水,并且不介意是否存在延迟

我们的目标:

减少响应时间: 及时处理用户的输出并且尽快将输出提供给用户
减少平均响应时间的波动: 在交互系统中,可预测性比高差异性低平均更重要
增加吞吐量: 减少开销(操作系统开销,上下文切换);系统资源的高效率用(CPU,IO设备)
减少等待时间: 减少每个进程的等待时间

在这里插入图片描述

评价指标

CPU使用率: CPU处于忙状态所占时间的百分比
吞吐量: 在单位时间内完成的进程数量
周转时间: 一个进程从初始化到结束,包括所有等待时间所花费的时间(等待时间 + 服务时间)
等待时间: 进程在就绪队列中的总时间（处于就绪态进程多久才能变成运行态）
响应时间: 从一个请求被提交到产生第一次响应所花费的总时间

公平的定义

举例:
- 保证每个进程占用相同的CPU时间
- 这公平嘛?如果一个用户比其他用户运行更多的进程怎么办
举例
- 保证每个进程都等待相同的时间
公平通常会增加平均响应时间

🌗3. 调度算法

FCFS (先来先服务)
- First come, First Served
SPN(SJE) SRT （短进程优先(短作业优先)短剩余时间优先)
- Shortest Process Next(Shortest Job First) Shortest Remaining Time
HRRN (最高响应比优先)
- Highest Response Ratio Next
Round Robin （轮循）
- 使用时间切片和抢占来轮流执行任务
Multilevel Feedback Queues （多级反馈队列）
- 优先级队列中的轮循
Fair Share Scheduling （公平共享调度）

🌔3.1 FCFS (先来先服务)

在这里插入图片描述

优点:

简单

缺点:

平均等待时间波动较大
花费时间少的任务可能排在花费时间长的任务后面(没有考虑抢占)
可能导致IO和CPU之间的重叠处理
- CPU密集型进程会导致IO设备闲置时,IO密集型进程也在等待

🌔3.2 SPN(不可抢占短作业优先) SRT (可抢占短作业优先)

选择预测的完成时间来将任务入队

当P_w 在执行的过程中，又来了一个进程它执行的时间很短，此时有俩种策略：抢占和不抢占

可以是抢占的或者是不可抢占的
- 不可抢占：当前进程继续执行，新来的花费时间短的进程，排到就绪队列的最前面，不会打断当前正在运行的进程
- 可抢占：P_w 当前进程，正在执行时，它本来执行时间比较久，但是当执行完一个时间片后，例如执行时间是8，此时来了一个新进程P_a 执行时间是5。此时P_w从运行态变到就绪态，把它重新挂到就绪队列中去，P_a占用CPU执行

SPN最大好处是最优平均等待时间最少
在这里插入图片描述

问题

可能导致饥饿
- 连续的短任务流会使场任务饥饿
- 短任务可用时的任何场任务的CPU时间都会增加平均等待时间
需要预测未来
- 怎么预估下一个CPU突发的持续时间
- 简单的解决: 询问用户
- 如果用户欺骗就杀死进程
- 如果不知道怎么办?

🌔3.3 HRRN(最高响应比优先)

前面SPN 只是考虑任务运行时间，而HRRN进行了优化多考虑了一个等待时间
公式：R=(等待时间+执行时间)/执行时间

问题
这个算法，不考虑抢占，当遇到优先级更高的，无法解决

🌔3.4 Round Robin(轮循)

使用时间切片和抢占来轮流执行任务

在这里插入图片描述
例子

从图中发现这个Round Robin时间依旧很长

问题
RR花销: 额外的上下文切换
时间量子太大:

等待时间过长
极限情况退化成FCFS

时间量子太小:

反应迅速
吞吐量由于大量的上下文切换开销受到影响

目标:

选择一个合适的时间量子
经验规则: 维持上下文切换开销处于1%以内

🌔3.5 Multilevel Feedback Queues(多级反馈队列)

综合RR和短路优先等特点

就绪队列被划分成独立的队列:

比如前台(交互),后台(批处理)

每个队列拥有自己的调度策略:

比如前台(RR),后台(FCFS)

调度必须在队列间进行:

固定优先级:
先处理前台,然后处理后台;
可能导致饥饿

时间切片:
每个队列都得到一个确定的能够调度其进程的CPU总时间;
比如 80%使用RR的前台,20%使用FCFS的后台