【说在前面的话】
在前面文章中,我们介绍了实时性的基本模型、并分析了实时性窗口内不同位置的时间对整个系统的价值,得出了一个结论——实时性窗口中越靠前的时间对系统中的其它任务越有价值;当一个有实时性要求的事件发生时,如果“不顾其它任务、自私自利”——只“单纯”考虑以越快越好的速度尽快完成当前的事件处理,会给整个系统的实时性带来毁灭性的结果——事实上,当所有任务都采取这一策略时,系统中没有任何一个任务的实时性是可以确定得到保证的。关于以上的结论,如果你还没有阅读过前一篇文章、或是对上述结论仍然抱有疑惑,可以单击《实时性迷思(1)——”快是优点么“?》进行阅读。
其实,在上一篇文章的留言区,很多朋友除了热烈讨论以外,还针对原文中的例子提出了“将任务拆分成小块进行时间片轮转”的解决方案,认为这样就可以解决文中提出的实时性矛盾。究竟时间片轮转能不能确保实时性?相信在阅读完本文以后,你一定可以做出自己的判断。也欢迎将你的想法在评论区留言。
【正文】
在讨论系统实时性的问题时,我们常常会跳过一个非常重要的步骤——证明当前系统在理论上是否有解——而直接进入讨论“如何确保具体任务实时性的方法”中来。这就好比看到一个浑浊的池塘,首先不调查是否可能有鱼,而直接开始着手钓鱼一样——也许大概率有鱼而你又运气不错,皆大欢喜;又或者根本污染严重鱼早就缺氧死光了,你却以为是自己运气不好,或者是技术不佳,悻悻而归——这实在是太可笑了。
那么,让我们明确一下这里首先需要面对和解决的问题吧:
-
在一个多任务系统中,有一部分(或者全部)任务拥有实时性要求;
-
对于这些有实时性要求的任务来说,任何一个任务在任何一种情形、哪怕是极小的概率下、存在无法满足实时性的可能,整个系统就判定为无法满足实时性要求;
-
由于上述判定条件过于苛刻,所以工程实践中,我们一般退而求其次,转而寻找一定无法满足实时性的情况,即:
-
如果在极其理想的条件下,可以通过数学方法证明这些任务的实时性一定无法得到满足,则需要调整硬件环境,或者对任务进行重新规划、降低实时性要求;
-
如果在极其理想的条件下,证明系统的实时性可以得到保证,则我们只能假设:可能存在一种方式让当前系统的实时性得到保证——此时我们可以进入下一阶段的讨论——也就是如何设计系统、将理论上证明可能做的事情变成既成事实。
-
如果上面的描述让你摸不着北,其实也可以换一种简单的说法:
-
如果数学上都已经能证明实时性得不到保证了,咱们就别折腾了;
-
如果数学上证明有希望,咱们再继续讨论实施方法——究竟最终能不能做到——事在人为,结果另说。
那么这是个怎样的数学模型呢?请大家翻出小学课本,学过除法和百分数的那个年级就行:
先说结论:
-
我们就是要计算每个实时性任务可能占用的最大CPU资源,并用百分比表示;
-
计算所有实时性任务所占用CPU资源的总和(将百分比累加起来);
-
如果超过100%,则整个实时性必然得不到保证;
-
如果没有超过100%,则可以判定在理想状况下,系统的实时性是有可能得到保证的;
-
-
实践中,距离100%越远,则可能性越大。如果卡着100%或者99%则相当危险,甚至可以稳妥的判定为不满足。
怎么样?道理是不是很简单?那么具体怎么计算呢?
-
观察此前介绍的实时性模型可以发现,无论是“实时性窗口”,还是“处理事件所需的时间” 都是表示时间长短的量;
-
其中,“实时性窗口” 是根据具体应用需要,由自于客观物理世界的时间要求所决定的,翻译成人话就是:“如果不在某一时间内完成任务,就会受到牛顿的毒打!”
-
实时性窗口还隐含了另外一个重要的假设,即,最差情况下,这个事件可能会以实时性窗口所代表的时间间(Interval, Period)隔周期性的发生——正可谓一波刚平一波又起(绅士们,我就不配图了
)。
-
“事件处理所需时间”,故名思意,就是CPU执行事件处理程序所需的时间。这里其实涉及到另外一个非常关键的问题——确定性(Deterministic):说白了,就是“最起码”要你能够拍胸脯打包票——执行这个任务所花的时间存在一个最大值(上界),并且这个上界是稳定可靠的——这只是确定性的最低标准;有时候某些应用对确定性的要求高的乍舌,比如,系统会强硬的规定:执行时间只允许在某一个非常小的范围内微弱的波动,做不到就直接判定为不满足“确定性”要求(例如很多车载系统中所使用的ECU就是这样),从而整个系统的实时性也成了空中楼阁。
为什么确定性如此重要呢?你想一想,如果一个满口跑火车的人跟你做了个保证:“明天股市一定暴涨,你赶快满仓”,你真敢根据这样的信息来做决策么?
在实时性系统中,任务执行时间是一个非常关键的指标,它直接关系到任务实际占用系统资源的百分比,如果这个数据不是“确定的”,我们又如何“确定的说”:系统一定能满足实时性要求呢?
这里有一个很重要的结论,大家可以拿小本本记下来:
实时性不一定要求系统跑的越快越好,但一定要求系统是具有高度确定性的。
这就是为什么,低频率低性能的Cortex-M和高频率高性能的Cortex-R都能用于实时系统;而高频率高性能的Cortex-A却无法满足“硬实时”的要求(因为Cortex-A使用MMU,理论上由实现虚拟地址空间导致的存储器访问时间是不确定的,因此建立在MMU基础上的任务执行就是无法满足确定性要求的)。
-
值得强调的是,假设事件处理程序的代码是一样的,那么很容易理解:当CPU频率升高的时候(CPU单位时间内可以执行的指令增加的时候),事件处理所需的时间就越短。
基于以上事实,我们可以设想一个严格的理想状况:
-
某个事件已“实时性窗口”所表示的时间间隔(Tw)周期性的发生;
-
在这个周期内,要消耗时间(Th)来处理这个事件;
则当前实时性任务所消耗的CPU资源百分比为:
这里的
就是“事件n”的CPU资源占用。
【反复横跳的代价】
不知道你还记不记得本文一开始我们试图讨论的那个问题:即,时间片轮转是否对实时性的保证有意义?经过前面的理论准备,我们现在就有了明确而清晰回答这个问题所需的所有条件:
已知的事实如下:
-
CPU频率不变的情况下,CPU的可用资源是固定的;
-
实现时间片轮转的方法有多种多样:比如,纯粹的合作式轮转(诸如裸机中的switch状态机,或者是基于函数指针的合作式调度器);又或是操作系统下,拥有相同优先级任务间所使用的可抢占式时间片轮询,即Round-roubin模式(详情请参考《【解惑】到底是“时间片”还是“分时轮询”?》)。
-
无论采用哪种时间片轮转方式,任务的切换都是有代价的。比如,裸机中,进出函数所需的跳转代价、局部变量在栈中重建的代价(详情参考《漫谈C变量——夏虫不可语冰》);操作系统中任务调度的代价等等。
-
在存量是固定不变的前提下,任务切换越频繁,则切换所消耗的CPU时间就越多,因此实际用于实时性任务处理的CPU资源就越少
结论:频繁任务切换对系统实时性是有害的;由于频繁时间片轮转会导致大量不必要的任务切换,因此对实时性总体上来说是有害的。
推论:任务切换对实时性系统来说是必要的,但一定要越少越好——拒绝花拳绣腿的反复横跳,只做真正有必要的任务切换。
很不客气的说,很多人一直把并发、甚至(仅仅只是并发其中一种实现方式的)“时间片轮转”当成“确保实时性的沙子”——不仅一头扎进去而不自知,还对周围的人传授自己的成功经验——实在是让人扼腕叹息。
【结语】
本文的结论实际上从本质上传达了一个信息:无论是裸机还是操作系统环境,多任务都是可以实现的——这是并发技术的本质所决定的。时间片轮转只是裸机和操作系统环境下常见的、“无脑”实现并发的一种方式——或者说,时间片轮转的作用只是实现并发而已,它不仅与实时性的保证无关,甚至是有害的。
那么,假设,在通过数学方式证明了:“可能存在一种解来满足系统的实时性要求”,那么具体有什么方法能够实现它呢?欲知详情,请听下回分解。
如果你觉得我的文章对你有帮助,引起了你的思考,欢迎点赞、转发、收藏三连;如果你单纯就是想催更,没有比打赏更有效的了~