是不是所有操作系统在CPU层面上都是通过时间片轮转的形式来运行程序的，如果是的话那么无论什么实时操作系统、什么多用户操作系统、什么网路操作系统什么的其实并无本质上的区别？

顺便问一下实时操作系统究竟是什么意思，说什么实时操作系统能够在规定的时间内完成任务，可现在的CPU计算能力不都很强吗，不也能很快的完成任务吗，为什么要加一个规定时间呢？

是不是所有操作系统在CPU层面上都是通过时间片轮转的形式来运行程序的

不是，还有批处理系统、优先顺序抢占式调度系统。分时复用的办法很多，时间片轮转只是其中一种。

至于「实时操作系统」、「多用户操作系统」、「网路操作系统」，并不是按照调度方式分类的，不要搞混。

实时操作系统究竟是什么意思

首先需要明确实时操作系统（RTOS）和实时应用程序（real-time application）的区别。RTOS的作用是运行RT-App，因此RTOS的定义就是能够运行RT-App的操作系统。RT-App就是满足实时性约束（real-time constraint）的应用程序。

所以问题的关键就变成了「实时性约束」的定义。教科书上的定义往往是这样的：能够保证在任何情况下，总能在时间T之内，对外部事件（event）给出响应（response），这个时间T也称为截止时间（deadline）。

（软体+硬体=系统，这里并没有涉及到操作系统。系统满足实时性约束，它就是实时系统。实时系统不使用OS也是可以的，同样，使用了RTOS，照样可以开发出不满足实时性约束的系统）

实时系统不需要运行得很快，我们关注的不是响应event的平均时间，而是响应event的最坏情况时间，也就是上限（deadline）。

现在考虑一个使用RTOS的实时系统，为了让系统满足实时性，要求系统接收到event时，RTOS要在时间T1之内切换到task，task要在时间T2之内完成对event的响应，这样整个系统就可以在时间T1+T2内完成事件响应。

RTOS需要关注的，就是这个T1，也就是能不能在一个固定的时间上限以内完成任务调度和切换。为了保证最坏情况，RTOS甚至会牺牲平均性能。

通用OS一般会追求较低的平均调度耗时，偶尔出现调度超时是可以接受的，因此会出现用户操作长时间无响应。对于RTOS，调度超时不可以接受。

题主真正的问题不在系统层面，而是一个抽象层次的问题；如果我们说CPU都是用硅做的，那它们是不是本质上并无区别呢？宇宙万物都是由粒子构成的，那是不是本质上就并无区别呢？

显然，把抽象层次提高到一定程度之后，你总会发现共性，非要说这些共性就是本质相同，那也并不能说错，只不过没什么意义而已。

那么操作系统是不是分时复用呢，不抬杠的说，是的；那它们都一样吗？如果你看调度演算法（也就是分时复用的策略），那肯定还是不同的。

实时操作系统就是分时策略上，保证任务一定能够在实时间隔内得到时间片，和我们平时用的非实时系统当然是很不一样的。

比如你有个音频处理任务必须要在30MS内完成，OK，现在有个Excel处理要跑1个小时，它已经占住CPU时间片了，非实时系统不调度你就慢慢等吧，CPU再快，也有撑破实时的计算任务。

并不是全部时间片轮转的。

比如有的是FIFO，线程主动挂起才会切换出去。

cpu计算能力强，不代表响应时间快。简单的可以看看安卓跟ios的界面操作对比。安卓吃亏的地方不是cpu性能不够，而是调度演算法，对界面响应这块不是实时调度的。

比如汽车，就是实时系统，踩刹车，油门，要马上给出反馈，如果反馈比较慢，操控性就差，还容易出安全事故。

除了调度要实时以为，很多演算法都要调整，比如内存分配，要采用稳定开销的演算法，而不是时快时慢的演算法。比如删除队列，如果是普通单链表，那么要删除头部的话就很快，要删除尾部的话就要遍历一遍整个队列，如果队列很长，就比较耗时，这种就是时快时慢的演算法。对普通系统来说，平均耗时不高就行了，对实时系统来说，期望每次都能稳定在一个范围内，可以不快，但要可期。

本质上都是中断机制。

时间片中断只是中断的一种，所以确实可以认为，实时操作系统在本质上和别的操作系统一样。

孙悟空、猪八戒、沙僧三个人轮流玩一台游戏机，每人轮流玩5分钟。

如果把游戏机看作CPU的话，孙悟空、猪八戒、沙僧就是三个任务，时间片是5分钟。

假如现在正轮到八戒玩

唐僧来了，也想玩

如果唐僧要八戒限时滚出去，要自己上去玩，就是实时操作系统。唐僧下来后，八戒也不一定接著继续玩，谁的优先顺序最高，轮到谁玩。

如果唐僧来了后，乖乖地等八戒把5分钟用完，乖乖地排队，是排在悟空前面、还是后面，看人品（优先顺序），然后才能轮到自己玩，就是非实时操作系统。

现在的应用程序不是你写的helloworld，运行一下就结束退出了。大部分应用软体都是无限死循环，一直在运行，如果你不主动关闭它，会一直在运行。当多个软体同时运行时，这就要求我们CPU要分配合适的时间片给它们，轮流执行。

我们日常使用的Windows、Linux操作系统一般都是非实时操作系统，时间片为1ms甚至更短，只要CPU的速度足够快，切换的速度足够快，让你感觉就是多个任务同时在运行：你可以一边听歌、一边聊天、一边写程序。其实后台这些程序一直在轮流占用CPU运行。等你开的程序足够多了，内存满了，有部分程序交换到硬碟里的交换分区去了，再切换回来执行的时候，你才有可能明显感到延迟和卡顿。此时你可能感觉很不爽，顶多骂两句：什么破电脑，卡得很！接著继续玩。

实时操作系统一般用于航空航天对时间要求非常高的场合，火箭飞行每秒钟几十公里，遇到问题时要在规定的时间限制内抢占CPU解决。如果像非实时操作系统那样，遇事不要慌，先发个朋友圈，排排队等他一段时间，火箭早就飞出去几十米开外了，误差很大。

修改了一下：实时并不是立刻马上，这个很难，但最多等一个时钟节拍：tick。所谓实时就是说：可以保证在限定的时间内能抢占到CPU执行。每一个OS的时钟节拍，操作系统的调度器都要让最高优先顺序的任务去执行。只要时钟节拍够快，就可以做到实时。

RTOS 没有时间片的，优先顺序一样的情况下当前进程不主动释放就不会切换

实时操作系统在有更精准控制需求的地方用的到

比如控制无人机，慢一点点就可能出大问题，导致无人机翻掉。容不得os随意调度线程带来的延迟

反对题主把RTOS理解成时间片调度。以了解的人最多的μC/OS-II为例。任务调度函数有两个，OSSched()和OSIntExit()，前者放在systick里面，为OSTimeDly()及其扩展函数服务，用户是看不到的，也不能引用，后者由用户放在中断代码的最后，比如某个任务pend在sem上，中断中postsem，那么执行OSIntExit()就会引发一次任务调度，中断结束后这个任务就会被执行。

那么基于μC/OS-II的代码就有两种极端的写法，一种是只有OSTimeDly()没有OSIntExit()，这种代码正如题主所述，是基于时间片的，按时间片各个任务轮流执行。另一种极端的写法就是没有OSTimeDly()只有OSIntExit()，例如放在串口中断、GPIO变化中断里面，这种写法的代码完全不符合题主的描述，但却是完全可以正常工作的，跟时间片没有任何关系，是外部输入（串口，GPIO……）的变化引发任务调度。

推荐阅读：
相关文章