[操作系统OS]第七章:CPU调度

一、基础概念

CPU调度:从就绪队列中挑选一个进程/线程作为CPU将要运行的下一个进程/线程
为此我们需要一个调度程序(挑选进程/线程的内核函数),并且在什么时机下执行这个调度程序:
从一个状态到另一个状态的时候会发生调度

当一个进程从运行状态切换到等待状态,或者运行中止时就会触发CPU调度。

调度方式

目前常用的调度方式有两种:

  1. 不可抢占式

调度程序必须等待事件结束才能切换(效率低,一般不采用)

  1. 抢占式
  • 调度程序在中断被响应后执行
  • 当前的进程从运行切换到就绪,或者一个进程从等待切换到就绪(进入就绪状态会进行抢占CPU)
  • 当前运行的进程可以被换出(和第一条类似,就是一个进程终止后回去选择下一个要执行的进程,从而触发抢占CPU)

抢占式说白了就是通过调度算法得出一个想要执行的进程进行切换。
以上调度方式一般发生在用户态,内核态也可能涉及到是否抢占。新的操作系统也支持了内核态中进行抢占式CPU调度,以此来获得更好的性能。


二、调度原则


可以出图中看出:程序运行时,CPU会在突发和I/O中交替

  • 每个CPU调度决定都是关于在下一个CPU突发时将哪个进程工作交给CPU
  • 在时间分片机制下,线程可能在结束当前CPU突发前被迫放弃CPU

所以如何更好的占用CPU资源,需要我们去设计对应的CPU调度算法,由此我们可以从一下维度去评判一个调度算法的好坏:

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

从公平的角度来说,其实就是期望每个进程占用相同的CPU时间,每个进程都有相同的等待时间。但其实实际角度来说是不可能做到完全公平的,公平通常会增加平均响应时间,而且用户对于每个进程的使用时间也不是公平的。


三、调度算法

FCFS先来先服务

使用FIFO队列,如果进程在执行中阻塞,那么CPU会选择下一个进程进行执行。

这种算法的优点就是实现简单,但是缺点有很多:

  • 进程的平均等待时间波动很大,因为其中没有涉及抢占
  • 花费时间少的进程有可能在花费时间长的进程的后面,一直不能执行
  • 可能会导致IO和CPU之间重叠处理,比如:CPU密集型进程会导致IO密集型线程在等待执行,然而此时IO设备正处于空闲的状态

SRT短剩余时间优先


其实就是选择执行剩余时间最短的进程进行执行,所有的进程都会被赋予一个推测的执行时间,根据这个推测时间的长短在readyQueue中进程由小到大的排序,CPU每次执行队列开头的进程。它可以是抢占式的或者非抢占式的:
非抢占式
当一个任务正处于执行时,这时有一个新的进程过来,如果正在执行的进程的此时的剩余执行时间比新的进程的执行时间更长,那么CPU也不会切换进程执行,而是等到当前线程执行完成后,再执行新的进程。
抢占式
抢占式的方法才是真的SRT短剩余时间优先算法,对于上述场景,CPU会阻塞当前进程,优先执行新的进程。
优缺点也很明显:
优点:平均的周转时间最少

可以看出下面的SRT进程的平均周转时间会更短
缺点:

  • 可能导致需要长时间执行的进程的饥饿,因为一直会被插队
  • 短执行时间任务执行都会导致后续长时间执行任务的等待时间增加

其中对于一个进程的执行剩余时间的估算是通过历史时间分配情况来预估的(根据该进程之前花费了多少时间来预测它将花费多少时间来执行)

HRR最高相应比优先

在原基础上考虑了等待时间以此改善了饥饿现象,其中响应比的计算方式为:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l6SOCwQ4-1689697239744)(https://cdn.nlark.com/yuque/__latex/6324c68919e9dd89649e3716c9b3a344.svg#card=math&code=R%28%E7%9B%B8%E5%BA%94%E6%AF%94%29%20%3D%20%5Cfrac%7BW%EF%BC%88%E7%AD%89%E5%BE%85%E6%97%B6%E9%97%B4%EF%BC%89%20%2B%20S%EF%BC%88%E6%89%A7%E8%A1%8C%E6%97%B6%E9%97%B4%EF%BC%89%7D%7B%20S%EF%BC%88%E6%89%A7%E8%A1%8C%E6%97%B6%E9%97%B4%EF%BC%89%7D&id=HTnDP)]
该算法会选择队列中R值最高的进程优先执行,并且是非抢占式执行,这么做的目的在于:关注了进程的等待时间,防止某些执行时间很长的进程无限期推迟执行

Round robin 轮询

也就是时间片的调度方法,在一个叫做量子切片或者时间切片中对离散单元分配CPU。换句话来说,就是定义了一个时间片长度,每个进程都可以执行这个时间长度,获得这个时间长度的CPU来运行。到了时间之后就轮到下一个进程去执行。
对于这个时间片的长度基本都是靠经验来定义,一般需要维持在开销的百分之一以下就是可以接受的。
本算法的优点就是:公平,公平,还是 t** 公平!
缺点:上下文频繁切换开销太大了,而且如果时间片太大,等待的时间就会过长,极端情况会演化为FCFS,反之如果太小,上下文切换频繁,吞吐量则会受到影响

多级反馈队列(Multilevel feedback queues)

该算法按照优先级分了多个队列,优先级越高分到的时间片就越短,相反优先级越低分到的时间片就越长。IO密集型任务,就放在高优先级队列,因为基本不需要什么CPU;CPU密集型任务就放在低优先级队列,因为占用CPU会比较多。
一个进程可以在不同的优先级队列中移动,如果进程在当前的时间片中没有完成任务,那么就移动到低一级的优先级队列中,下次分配更长的时间片去执行。

公平共享调度

站在用户的角度实现公平共享CPU资源,它考虑了以下情况:

  • 一些用户组比其他用户组更重要
  • 保证不重要的组无法垄断资源
  • 未使用的资源按照每个组所分配的资源的比例来分配
  • 没有达到资源使用目标的组获得更高的优先级

不同调度模型的评价准则

确定性建模:确定一个工作量,然后计算每个算法的表现
队列模型:用来处理随机工作负载的数学方法
实现/模拟:建立一个允许算法运行实际数据的系统

四、实时调度

实时系统

正确依赖于其时间和功能两方面的一种操作系统。
性能指标:

  • 时间约束的及时性
  • 速度和平均性能相对不重要

主要特征:时间约束的可预测性
强实时系统
需要在保证的时间内必须完成某些重要的任务
弱实时系统
要求重要的进程的优先级更高,尽量完成,并非必须完成
硬时限

  • 如果错过了最后期限,可能会发生灾难性或非常严重的后果;
  • 必须验证:在最坏的情况下也能够满足时限吗?
  • 保证确定性;

软时限:

  • 理想情况下,时限应该被最大满足。如果有时限没有被满足,那么就相应地降低要求;
  • 尽最大努力去保证;

调度算法

静态优先级调度:运行之前优先级就是确定的;
动态优先级调度:优先级在运行中是动态变化的;
RM(Rate Monotonic)速率单调调度

  • 最佳静态优先级调度
  • 通过周期安排优先级
  • 周期越短,优先级越高
  • 先执行周期最短的任务

EDF(Earliest Deadline First)最早期限调度

  • 最佳的动态优先级调度
  • Deadline越早,优先级越高
  • 先执行Deadline最早的任务

多处理器调度与优先级反转

当今操作系统中的CPU采用了多核心架构,所以我们需要使得在多核CPU环境下多个核心的负载尽可能均衡。
还有对称多处理器(SMP),其中每个处理器运行自己的调度程序,需要在调度程序进行中同步。

所以多处理器环境下需要另外适配的多处理器调度算法来进行控制,在这里不做过多讲解。
在这种情况下,可能会发生优先级反转的情况:
优先级反转可以发生在任何基于优先级的可抢占的调度机制,当系统内的环境强制使高优先级任务等待低优先级任务时发生。
优先级反转的持续时间取决于其它不相关任务的不可预测的行为。在这种情况下,高优先级可能比低优先级任务晚完成。

  1. 首先时间轴上,只有T3有任务,所以在t1-t3是T3在执行;
  2. 到t2的时候,T3访问了一个蓝色的贡献资源(T1在t4时也要用);
  3. 到了t3时,T1出现了,它的优先级更高,所以T3中断,T1执行;直到t4时刻,T1需要使用T3占用的蓝色资源释放后才能继续执行,所以把CPU让给T3;
  4. t4-t5是T3执行,t5时,此时T2出现,优先级比T3高,所以T3终止,执行T2;
  5. T2执行完后,T3在时间t6-t7中释放了蓝色共享资源,T1才能继续执行。

那么优先级更高的T1,需要等T2运行完才能执行。
总结来说:其实就是高优先级的任务因为资源被低优先级的任务抢占,所以必须要等到低优先级的任务执行完之后才能继续向下执行,从而有了高优先级的任务比低优先级任务晚执行完成的情况。
解决方法(优先级继承)

  • “拥有资源”的优先级和“所有可以锁定该资源任务中优先级最高的那个任务”的优先级相同
  • 除非当前进程的优先级高于系统中所有被锁定的资源的优先级,否则任务尝试执行临界区的时候会被阻塞;
  • 持有最高优先级信号量锁的任务,会继承被该锁所阻塞的任务的优先级。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值