作者： GorgonMeducer 傻孩子
首发：裸机思维
【说在前面的话】
在前面文章中，我们介绍了实时性的基本模型、并分析了实时性窗口内不同位置的时间对整个系统的价值，得出了一个结论——实时性窗口中越靠前的时间对系统中的其它任务越有价值；当一个有实时性要求的事件发生时，如果“不顾其它任务、自私自利”——只“单纯”考虑以越快越好的速度尽快完成当前的事件处理，会给整个系统的实时性带来毁灭性的结果——事实上，当所有任务都采取这一策略时，系统中没有任何一个任务的实时性是可以确定得到保证的。关于以上的结论，如果你还没有阅读过前一篇文章、或是对上述结论仍然抱有疑惑，可以单击《实时性迷思(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频率不变的情况下，CPU的可用资源是固定的；
- 实现时间片轮转的方法有多种多样：比如，纯粹的合作式轮转（诸如裸机中的switch状态机，或者是基于函数指针的合作式调度器）；又或是操作系统下，拥有相同优先级任务间所使用的可抢占式时间片轮询，即Round-roubin模式（详情请参考《【解惑】到底是“时间片”还是“分时轮询”？》）。
- 无论采用哪种时间片轮转方式，任务的切换都是有代价的。比如，裸机中，进出函数所需的跳转代价、局部变量在栈中重建的代价（详情参考《漫谈C变量——夏虫不可语冰》）；操作系统中任务调度的代价等等。
- 在存量是固定不变的前提下，任务切换越频繁，则切换所消耗的CPU时间就越多，因此实际用于实时性任务处理的CPU资源就越少
结论：频繁任务切换对系统实时性是有害的；由于频繁时间片轮转会导致大量不必要的任务切换，因此对实时性总体上来说是有害的。
推论：任务切换对实时性系统来说是必要的，但一定要越少越好——拒绝花拳绣腿的反复横跳，只做真正有必要的任务切换。
很不客气的说，很多人一直把并发、甚至（仅仅只是并发其中一种实现方式的）“时间片轮转”当成“确保实时性的沙子”——不仅一头扎进去而不自知，还对周围的人传授自己的成功经验——实在是让人扼腕叹息。
【结语】
本文的结论实际上从本质上传达了一个信息：无论是裸机还是操作系统环境，多任务都是可以实现的——这是并发技术的本质所决定的。时间片轮转只是裸机和操作系统环境下常见的、“无脑”实现并发的一种方式——或者说，时间片轮转的作用只是实现并发而已，它不仅与实时性的保证无关，甚至是有害的。
那么，假设，在通过数学方式证明了：“可能存在一种解来满足系统的实时性要求”，那么具体有什么方法能够实现它呢？欲知详情，请听下回分解。
专栏推荐文章
如果你喜欢我的思维，欢迎订阅裸机思维
版权归裸机思维（傻孩子图书工作室旗下公众号）所有，
所有内容原创，严禁任何形式的转载。
