时间分区实时操作系统就是扯淡

现代实时操作系统一般都有内存分区管理功能，它是在硬件MMU单元的支持下，对内存访问地址进行监视或转换实现的。但现在竟然有人将这种空间分区的概念生搬硬套，非要用到时间上来，搞了个"时间分区实时操作系统"。这种探索本身并没有问题，但可恨的是还有一堆不明所以的人看到个"高大上"的概念，就闭着眼睛，非得上，骗人骗己，实在可恶！

那么为什么我说"时间分区实时操作系统"就是扯淡呢，因为它和实时性天然互斥。打个比喻：一间厕所，现在分成了10个隔间，大家各用各的，互不干扰。但如果要是规定每人每次只能用1分钟呢，那场面，不堪入目。

注意，这里说的是实时场景不适合使用这种时间分区的调度策略，但任何东西都有其适合的使用场景。比如游乐场的过山车，就是一个人1分钟，坐完就得下来，要想再坐，那就得重新排队。至于计算机，其实windows、linux等用到的"时间片轮转"调度策略就类似于"时间分区"调度策略，只是"时间分区"调度策略的任务执行时间更加确定，而"时间片轮转"调度策略却能更充分利用时间资源。但是很可惜，这种"分时（时间片轮转和时间分区都属于分时）"调度策略天然得破坏了实时性，会造成任务执行的不连续、响应不及时等问题。

对于操作系统的任务调度策略选择，我们需要考虑以下几点：

1. 任务的时间圈大小，也就是一个任务执行完一遍所需要的时间；
2. 任务对时间的实时性要求；
3. 任务对时间的连续性要求；
4. 任务对时间的确定性要求。

下面就按照上述几点分别讨论各种场景下适合的任务调度策略：

1. 多用户交互场景，适用时间片轮转调度
   人的感官对时间的粒度感知通常是小于0.1s的，而且程序偶尔卡顿一下也无伤大雅，所以此种场景任务对时间的实时性和确定性要求都不高；交互程序渲染一次页面的时间圈通常很小，且对时间的连续性没有太高要求，只要在0.1s内完成渲染，用户一般就没有太大的不适。
2. 汽车安全系统，适用抢占式调度
   这种任务执行的时间圈也比较小，但对实时性要求极高，且任务执行过程中不能有较长时间的停顿。由于安全事故的发生是不确定的，所以也就谈不上时间的确定性了，一旦发生事故，就得立马处理。
3. 高性能计算，适用时间片轮转调度
   这种任务的时间圈很大，但是对时间的实时性、连续性和确定性要求都不高，所以如果要在跑着高性能计算任务的机器上再玩个扫雷，运行个命令行，是完全允许的。

以上几个场景我都没有提到"时间分区"调度策略，这是因为这种调度策略虽然带来了时间的确定性，但却无法充分利用时间资源，编程也不够简洁，所以更常用的是"时间片轮转"调度策略。只有在对时间的确定性有严格要求时，才能凑合使用。但此时用抢占式调度策略，再配合定时器定时唤醒和阻塞任务会更方便、更灵活。

再来总结对比下各种调度策略的特性：

	抢占式	时间片轮转	时间分区
时间实时性	√	X	X
时间连续性	√	X	X
时间确定性	√	X	√
资源利用率	√	√	X
编程简洁度	X	√	X

“分时"调度策略和"抢占"调度策略本身是互斥的，但如果非得把他们结合在一起，那么必须要让"分时"从属于"抢占”，而且这里的"分时"还只能是"时间片轮转"。这也是为什么现在主流的实时操作系统都是"抢占调度策略"主导，同优先级可以选择是否采用"时间片轮转调度"的原因。

下面对比下几种可能的结合方式的时间特性，其它结合方式根本不存在，所以不必参与比较：

	抢占式为主+同优先级时间片轮转	时间分区+分区内允许抢占
时间实时性	√	X
时间连续性	√	X
时间确定性	√	X
资源利用率	√	X
编程简洁度	X	X

从上表中可以看出"时间分区+分区内允许抢占"虽然可以实现，但完全就是一个怪胎，然而我真见到有人在搞得风生水起。

总得来说"时间分区"操作系统适用场景有限，且有更好的替代方案，非得将它和"内存分区"概念相提并论，那么我必须得说：它不配！