上一篇文章里所讲的, 时间片轮转、CPU快速切换,这算是 分时操作系统 的核心思想
它的设计目的很简单:
让尽可能多的程序，都觉得自己在被服务。
大概准时就够了,就算晚个几毫秒,也无伤大雅
但它的问题也很明显: 它无法保证最坏情况下的响应时间,高优先级任务也可能因为时间片机制而被延迟。
比如:如果开车撞墙了,安全气囊需要弹出来
![[分时操作系统和实时操作系统/1.png]]
这时候就会发现,如果还按分时操作系统这套思路来,会非常危险。
那么,实时操作系统 就来了,它的核心思想就是: 必须在截止时间之前完成任务
![[分时操作系统和实时操作系统/2.png]]
而它能做到这一点,一个很重要的原因就是 RTOS 的调度逻辑更看重: 优先级
回顾一下之前 分时系统 的时间轴:
![[分时操作系统和实时操作系统/3.png]]
再看 RTOS 的时间轴:
![[分时操作系统和实时操作系统/4.png]]
不过,实时也不是只有一种。
实时通常分成两类: 硬实时(Hard Real-Time) 和 软实时(Soft Real-Time)
简单来说,它们对应着两句话:
- 硬实时:绝对不能晚,后果无法接受
- 软实时:最好不要晚,体验变差,但结果还能接受
分别举个例子:
- 硬实时:安全气囊,心脏起搏器...
- 软实时:视频通话,音频播放...
那怎么判断一个场景到底需不需要硬实时？
你可以先别急着背定义,先看这个设备到底是在 直接控制某个动作,还是只是 把信息告诉你。
-
如果它是直接控制动作的,比如 安全气囊、心脏起搏器,那它就属于 硬实时。因为一旦晚了,后果就不是“体验变差”,而是真的可能出事。
-
如果它主要是把信息通知给你,比如 手机弹出地震预警,那它更接近 软实时。因为手机这一层更像是在通知人,真正要求极短时间内完成判断和响应的,通常是在更前面的监测和控制系统里。
还有一个很容易忽略的点: 手机里其实不只有一套系统在工作。
- 我们平时看到的 Android / iOS,主要负责应用、界面这些东西,它本质上更偏 分时系统
- 但像通信这类对时序要求很高的任务,往往不是直接交给这套通用系统慢慢调度,而是交给更专门的芯片和系统去处理
所以很多真正要求“绝对不能晚”的任务,通常不会直接压在通用操作系统身上,而是会交给更专门的硬件和系统来做。
总结
如果只用一句话去理解这篇,那就是: 分时操作系统追求的是“让大家都能轮到”,而实时操作系统追求的是“关键任务绝对不能错过时间”。
前者更适合应用、界面、多任务这些场景,后者更适合那些一旦晚了就可能出问题的控制场景。所以这两种系统不是谁替代谁,而是它们从一开始解决的就是两种完全不同的问题。
