cpu时间片原理说明

一、简介

1、cpu时间片的概念

时间片即CPU分配给各个程序的时间,每个线程被分配一个时间段,称作它的时间片,即该进程允许运行的时间,使各个程序从表面上看是同时进行的。如果在时间片结束时进程还在运行,则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束,则CPU当即进行切换。而不会造成CPU资源浪费。在宏观上:我们可以同时打开多个应用程序,每个程序并行不悖,同时运行。但在微观上:由于只有一个CPU,一次只能处理程序要求的一部分,如何处理公平,一种方法就是引入时间片,每个程序轮流执行。

2、cpu时间片基本原理

在早期的时间片轮转法中,系统将所有的就绪进程按先来先服务的原则,排成一个队列,每次调度时,把CPU分配给队首进程,并令其执行一个时间片.时间片的大小从几ms到几百ms.当执行的时间片用完时,由一个计时器发出时钟中断请求,调度程序便据此信号来停止该进程的执行,并将它送往就绪队列的末尾;然后,再把处理机分配给就绪队列中新的队首进程,同时也让它执行一个时间片.这样就可以保证就绪队列中的所有进程,在一给定的时间内,均能获得一时间片的处理机执行时间.

3、系统中cpu时间片是多久

Windows 系统中线程轮转时间也就是时间片大约是20ms,如果某个线程所需要的时间小于20ms,那么不到20ms就会切换到其他线程;如果一个线程所需的时间超过20ms,系统也最多只给20ms,除非意外发生(那可能导致整个系统无响应),而Linux/unix中则是5~800ms。

4、cpu时间片轮转机制(RR 调度)

时间片轮转法(Round-Robin,RR)主要用于分时系统中的进程调度。为了实现轮转调度,系统把所有就绪进程按先入先出的原则排成一个队列。新来的进程加到就绪队列末尾。每当执行进程调度时,进程调度程序总是选出就绪队列的队首进程,让它在 CPU 上运行一个时间片的时间。时间片是一个小的时间单位,通常为 10~100ms 数量级。当进程用完分给它的时间片后,系统的计时器发出时钟中断,调度程序便停止该进程的运行,把它放入就绪队列的末尾;然后,把 CPU 分给就绪队列的队首进程,同样也让它运行一个时间片,如此往复。

进程调度

采用此算法的系统,其程序就绪队列往往按进程到达的时间来排序。进程调度程序总是选择就绪队列中的第一个进程,也就是说按照先来先服务原则调度,但一旦进程占用处理机则仅使用一个时间片。在使用先一个时间片后,进程还没有完成其运行,它必须释放出处理机给下一个就绪的进程,而被抢占的进程返回到就绪队列的末尾重新排队等待再次运行。

处理器同一个时间只能处理一个任务。处理器在处理多任务的时候,就要看请求的时间顺序,如果时间一致,就要进行预测。挑到一个任务后,需要若干步骤才能做完,这些步骤中有些需要处理器参与,有些不需要(如磁盘控制器的存储过程)。不需要处理器处理的时候,这部分时间就要分配给其他的进程。原来的进程就要处于等待的时间段上。经过周密分配时间,宏观上就象是多个任务一起运行一样,但微观上是有先后的,就是时间片轮换。

实现思想

时间片轮转算法的基本思想是,系统将所有的就绪进程按先来先服务算法的原则,排成一个队列,每次调度时,系统把处理机分配给队列首进程,并让其执行一个时间片。当执行的时间片用完时,由一个计时器发出时钟中断请求,调度程序根据这个请求停止该进程的运行,将它送到就绪队列的末尾,再把处理机分给就绪队列中新的队列首进程,同时让它也执行一个时间片。

5、cpu时间片轮转调度算法

时间片轮转调度是一种最古老,最简单,最公平且使用最广的算法。每个进程被分配一时间段,称作它的时间片,即该进程允许运行的时间。

如果在时间片结束时进程还在运行,则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束,则CPU当即进行切换。调度程序所要做的就是维护一张就绪进程列表,当进程用完它的时间片后,它被移到队列的末尾。

时间片轮转调度中唯一有趣的一点是时间片的长度。从一个进程切换到另一个进程是需要一定时间的--保存和装入寄存器值及内存映像,更新各种表格和队列等。假如进程切换(process switch) - 有时称为上下文切换(context switch),需要5毫秒,再假设时间片设为20毫秒,则在做完20毫秒有用的工作之后,CPU将花费5毫秒来进行进程切换。CPU时间的20%被浪费在了管理开销上。

为了提高CPU效率,我们可以将时间片设为500毫秒。这时浪费的时间只有1%。但考虑在一个分时系统中,如果有十个交互用户几乎同时按下回车键,将发生什么情况?假设所有其他进程都用足它们的时间片的话,最后一个不幸的进程不得不等待5秒钟才获得运行机会。多数用户无法忍受一条简短命令要5秒钟才能做出响应。同样的问题在一台支持多道程序的个人计算机上也会发生。

结论可以归结如下:时间片设得太短会导致过多的进程切换,降低了CPU效率;而设得太长又可能引起对短的交互请求的响应变差。将时间片设为100毫秒通常是一个比较合理的折中。

通过以上的内容,我们已经了解了cpu时间片方面的相关知识了,对于时间片的基本原理以及轮转机制方面的内容,也可以多多的了解下。

二、原理

了解了上面的概念后,你可能对cpu的时间片认知还是懵懵懂懂的,它到底是怎么个原理?为什么要这么做?这么做有什么好处?与它相关的专业术语和理论又有什么关联性?我怎么能深刻的理解它的原理?接下来就是本文的重点内容,让我们来一起探索下。

1、类比生活场景解释cpu时间片的发展和理论原理

先来设定下生活中的场景和角色:

场景:餐馆

角色:

(1)厨师(专心炒菜)

(2)后厨帮手(负责给厨师打下手的学徒之类,负责备菜递盘等等相较为低级一些的事情)

(3)服务员(负责响应顾客,并且通知后厨顾客的需求)

(4)顾客(专心消费)

场景设定:店里依次排队进来了5个顾客,每个人都点了一个菜

核心问题:上菜速度怎么样?怎么最快的把菜炒完。

厨师怎么怎么处理顾客的点单,才能让顾客在最短的时间吃到菜

店里来了5个客人,每个人都点了一个菜,如下:

顾客1第一个下单:菜1——青椒炒肉——大约需要5分钟

顾客2第二个下单:菜2——土豆牛腩——大约需要25分钟

顾客3第三个下单:菜3——红烧鸡块——大约需要15分钟

顾客4第四个下单:菜4——青椒炒鸡蛋——大约需要3分钟

顾客5第五个下单:菜5——宫保鸡丁——大约需要4分钟

方案一:先到先得方法

按照先到先得方法最终到厨师手里的炒菜单顺序是:

1.菜1——青椒炒肉(5分钟)

2.菜2——土豆牛腩(25分钟)

3.菜3——红烧鸡块(15分钟)

4.菜4——青椒炒鸡蛋(3分钟)

5.菜5——宫保鸡丁(4分钟)

总耗时:5min+25min+15min+3min+4min=52min

各个顾客等待时间:

1.顾客1:菜1——青椒炒肉(5分钟)——等待5分钟

2.顾客2:菜2——土豆牛腩(25分钟)——等待30分钟

3.顾客3:菜3——红烧鸡块(15分钟)——等待45分钟

4.顾客4:菜4——青椒炒鸡蛋(3分钟)——等待48分钟

5.顾客5:菜5——宫保鸡丁(4分钟)——等待52分钟

平均等待时间:(5+30+45+48+52)/5=36分钟。

最长平均等待时间(最差情况):

1.顾客2:菜2——土豆牛腩(25分钟)——等待25分钟

2.顾客3:菜3——红烧鸡块(15分钟)——等待40分钟

3.顾客1:菜1——青椒炒肉(5分钟)——等待45分钟

4.顾客5:菜5——宫保鸡丁(4分钟)——等待49分钟

5.顾客4:菜4——青椒炒鸡蛋(3分钟)——等待52分钟

平均等待时间:(25+40+45+49+52)/5=42.2分钟。

这明显的处理效率不够,顾客很可能不愿意等待,从而使得顾客流失,那我们可以进一步优化,采用优先级方法处理(优先处理时间短的事情)。

方案二:优先级方法

1.菜4——青椒炒鸡蛋(3分钟)

2.菜5——宫保鸡丁(4分钟)

3.菜1——青椒炒肉(5分钟)

4.菜3——红烧鸡块(15分钟)

5.菜2——土豆牛腩(25分钟)

总耗时:3min+4min+5min+15min+25min=52min

各个顾客等待时间:

1.菜4——青椒炒鸡蛋(3分钟)——顾客4——等待3分钟

2.菜5——宫保鸡丁(4分钟)——顾客5——等待7分钟

3.菜1——青椒炒肉(5分钟)——顾客1——等待12分钟

4.菜3——红烧鸡块(15分钟)——顾客3——等待27分钟

5.菜2——土豆牛腩(25分钟)——顾客2——等待52分钟

平均等待时间:(3+7+12+27+52)/5=18.2min

但是这种情况是最理想的状态,有时候顾客到来和下单的时间不能确定,如果顾客2先到达并且下单,那么平均等待时间将变为(引入下单时间,以第一个顾客下单时间为基准):

1.菜2——土豆牛腩(25分钟)——顾客2下单——第一个优先级——等待25分钟

2.菜5——宫保鸡丁(4分钟)——顾客5在顾客2下单后1分钟后下单——第三个优先级——等待32分钟

3.菜1——青椒炒肉(5分钟)——顾客1在顾客2下单后2分钟下单——第四个优先级——等待37分钟

4.菜3——红烧鸡块(15分钟)——顾客3在顾客2下单后3分钟后下单——第五个优先级——等待52分钟

5.菜4——青椒炒鸡蛋(3分钟)——顾客4在顾客2下单后4分钟后下单——第二个优先级——等待28分钟

平均等待时间:(25+32+37+52+28)/5=34.8min。

虽然优先级算法可以节省一些场景的时间,但是受到实际下单时间的影响,可能性能还是不能够达到最优,那接着就引入了时间轮询方法。

方案三:时间轮询方法(就是我们本文的重点cpu时间片轮询)

首先,厨师手里的菜单如下,以5分钟为一个单位做为单个时间片处理结果将是:

1.菜2——土豆牛腩(25分钟)——顾客2下单——第一个优先级——制作5分钟后,暂停当前任务处理其他时间短的任务,第24分钟到28分钟第二次处理,第34分钟到38分钟第三次处理,第44分钟到48分钟第四次处理,第49分钟到53分钟第五次处理,共处理5次,总花费25分钟处理时间——等待25分钟

2.菜5——宫保鸡丁(4分钟)——顾客5在顾客2下单后1分钟后下单——第三个优先级——等待12分钟

3.菜1——青椒炒肉(5分钟)——顾客1在顾客2下单后2分钟下单——第四个优先级——等待17分钟

4.菜3——红烧鸡块(15分钟)——顾客3在顾客2下单后3分钟后下单——第五个优先级——第18分钟到23分钟处理一次,第29分钟到33分钟第二次处理,第39分钟到43分钟第三次处理,共处理3次,总花费15分钟处理时间——等待43分钟

5.菜4——青椒炒鸡蛋(3分钟)——顾客4在顾客2下单后4分钟后下单——第二个优先级——等待8分钟

平均等待时间:(53+12+17+43+8)/5=26.6min。

这时候无论顾客下单情况如何,都可以尽可能的让用户等待最少的时间。这就是时间片策略。

各个方案比较
维度先到先得优先级时间轮询
最差平均等待时间42.2min34.8min26.6min

这里可以看出,最差平均等待时间上,时间轮询策略是最优解。这也是当前cpu的时间片轮询策略的发展由来过程。

这时候,聪明的你会好奇,一个厨师只能在一个时间炒一个菜么?不能多几个锅灶,多几个厨师么?是的,可以,但是多请师傅,多增加锅灶就涉及到成本问题了。

在计算机领域,多请师傅意味着要增加cpu核,多给师傅配置锅灶要看师傅的能力(cpu是否支持处理多线程,如果师傅一个时间只能炒一个菜,那配置多余的锅灶也没有用,当师傅可以同时兼顾2个菜时,就是对应的cpu开启多线程,比如最常见的cpu双线程,一个cpu有两个线程)。因此,无论是增加cpu核,还是开启cpu多线程,都是需要硬件扩展和支持,而也对应着硬件成本的增加。而现在的芯片技术以及成本问题。也导致硬件不可能无限的扩增下去,我们仍然需要在调度策略上尽可能的利用硬件性能,争取最高的性价比。

2、cpu时间片专业术语中的原理说明

上面假设的餐馆场景,那实际在计算机中,他又分别对应什么呢。

场景:餐馆——计算机+操作系统

角色:

(1)厨师(专心炒菜)——cpu(专心处理计算)

(2)后厨帮手(负责给厨师打下手的学徒之类,负责备菜递盘等等相较为低级一些的事情)——各种缓存处理

(3)服务员(负责响应顾客,并且通知后厨顾客的需求)——中断

(4)顾客(专心消费)——应用程序

场景设定:店里依次排队进来了5个顾客,每个人都点了一个菜——系统有5个任务待执行

核心问题:上菜速度怎么样?怎么最快的把菜炒完。——系统性能怎么最高(即任务平均等待时间最短)

三、参考链接

1.cpu时间片的概念 - 简书 (jianshu.com)

2.几种CPU调度策略-腾讯云开发者社区-腾讯云 (tencent.com)

  • 4
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不会写代码的小可爱&&

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值