实时操作系统 (Real-time OS) 是相对于分时操作系统 (Time-Sharing OS) 的一个 概念。在一个分时操作系统中，计算机系统的资料会被平均的分配给系统内所有的工作。对于这些工作而言，它们似乎是在一个速度较慢、资源较少的虚拟系统上工作。 而这个虚拟系统所拥有的资源会和真实系统内等待执行的工作数有关。简单的说，如 果有 n 个工作要做，每一个工作就会分到 n 分之一的资源。
然而在一个实时操作系统之中，系统内有多少工作并不是那么重要。我们关心的 事一个工作在多少的时间内可以被完成。和分时操作系统最大的不同之处在于 “时限(deadline)”这个概念，实时操作系统通常会要求每一个工作在交付给系 统的时候同时也给定一个时限。实时操作系统的任务不只是要求完成每一个工作， 并且要按时给定的时限完成每一个工作。
所以我们可以看出这二个概念的不同之处，分时操作系统的重点在于”公平”， 而实时操作系统的重点在于”时限(timing constraint)”“。
任何时候。我不是开玩笑，当一个实时操作系统中的每一个工作都有相同的时限时， 它应该和分时操作系统用相同的方式工作。分时操作系统和实时操作系统的分野在于工作的特性而非操作系统工作的模式。
在很多的书及文献上我们可能会看到”硬实时(hard real-time)”和”软实时 ( soft real-time)”这二个名词。不同的人会给它们不同的意义，但大致来说它们是一组相对的概念。硬实时对满足时限的要求会比软实时来的严格。有些人会从 工作的特性上来分，硬实时工作 (hard real-time task) 通常指不能有任何差 错的工作而软实时则是指比较容许差错的工作。例如我们常会用核能电厂和看 VCD 为例，用在核能电厂的实时操作系统如果出了差错可能会导致严重的损害，然而 VCD Player 出了些差错不过是让使用者认清他所用的程序不够好而已。所以前者 是硬实时，后者是软实时。
但在大多数的状况下，分野并不是如此的清楚。做 VCD Player 的厂商当然不 希望它的 Player 老是出错，它也会希望 Player 用一个硬实时操作系统来驱动。 所以硬实时和软实时的差别可能只是分类学上的问题而已。
然而对于一般的应用而言，实时操作系统的意义在那里呢? 我们使用流览器看一 个网站时，如果结果在 0.5 秒内出现，我们可能会觉得非常舒服。如果结果在 2 秒才出现，可能会觉得有些延迟。但如果花上 30 秒才出现，那可能就没有人会等 到结果出现了。
对于我们而言，等个 3,5 秒可能觉得没什么。但也许 Bill Gates 不这么想， 他会算给你听他的一秒值多少钱! 所以不同的人可能会对延迟有不同的看法。即 时操作系统最大的优势就在于他可以为不同的工作提供”不同等级的服务( differentiated service)”。
一个对实时系统常有的误解是实时系统是一个高效率 (high performance) 的 系统，它会跑得比一般操作系统来的快，overhead 来得小。这其实是市场策略宣 传造成的影响。一大堆非常小的操作系统宣称它们是嵌入式实时操作系统 (embedded real-time OS)，这么一来”嵌入”、”实时”和”小”就被莫名其 妙的连起来了。实事上这三个是完全不相干的概念。”嵌入”指的是操作系统可 以在一些资源受限的环境，例如没有 disk，的情况下工作。”小”是指因为功能 简单，要求不多，所以操作系统可以写的很小，减少不必要的额外负担。这些都 和”实时”的概念完全没有关系。不幸的是，即使是学有专精的计算机工程师也常 把它们混为一谈。
为什么不用? 实时操作系统和分时操作系统并不是完全互斥的概念，我前面说过如 果一个实时操作系统中所有的工作都有相同的时限，那它应该会制造出和分时作业 系统相同的结果。
所以一个系统可以同时执行分时和实时的工作另一个常有的误解是实时的工作 应该比分时的工作先执行。这其实是不对的，实时的工作只是要求在时限内完成 而已，一个时限在 10 秒之后的工作没有道理一定要在现在立刻执行。太早完成 它没有任何好处，有时还会造成系统不必要的负担。
实时操作系统的优势在于它知道目前系统资源使用的状况，它能比起分时作业 系统更精准的控制系统资源的使用。对于分时操作系统而言，它无法预测一个工 作到底还须要花多少时间才能完成。因此对于比较重要的工作，唯一的方法就是 尽快的完成它。而实时操作系统可以预测工作完成的时间，因此它可以轻易的决 定工作要在什么时间被执行。
所以实时操作系统所做的事，不过就是一个更强大的 renice 指令而已。在 renice 中，你只能指定一个叫优先权 (priority) 的值。优先权越高的工作 在分时系统中会分到更多的时间，但多多少呢? 没人能回答这个问题，因为在 分时操作系统中不把它视为一个重要的事。
而实时操作系统的 renice 指定可以指定一大堆的参数，你可以指定前述的 时限 (deadline)，优先权 (priority)。还可以指定工作在单工状态下执行所 需的时间 (execution time)、工作应该在什么时候允许开始执行 (start time) 、什么时候就不应该再继续下去了(finish time)。当然过去二十年来在实时作 业系统理论上的发展使得我们还有更多更多的可能性来实作实时操作系统的 renice 指令。但简单的说，我们得到的是一个更强大的 renice 指令。它可以被用来更 精准的调整系统的整体效能。这也就是我为什么会认为，为什么不用实时作业系 统。
我的看法是，在将来的操作系统，实时会是一个和网络一样、是系统标准的功能。
和 Linux 其它领域一般，有一大堆的人都试图为 Linux 加上实时的功能。每个人 都有不同的看法，每个人看的角度也不相同，所以产生了各式各样的”real-time Linux OS”。在这里，我们看到了开放原始码 (open source) 在这个领域优势所 在。我们可以想见在不久的将来，这些各有专精的系统会自然的合并成一套非常好 用的实时操作系统。而不是相互用市场的策略恶性竞争。所以 open source 可以 提供我们一套更新、更好、更实用的实时操作系统。
接下来，我们先简介一下现存的各种 real-time Linux OS。
NMT RT-Linux
NMT 是新墨西哥科技大学(New Mexico Technology) 的缩写。这一套系统可以说是 所有 Real-time Linux 的鼻祖。它目前已经发展到 3.0 版。这个系统是由 Victor Yodaiken 和它的学生 Michael Barabanov 所完成。这个系统的概念是”架空” Linux kernel，使得它的 real-time 行程得以尽快的被执行。下面的图例说明了 NMT RT-Linux 和其它类似产品的系统架构。
你可以看到基本上RT-Linux 中的实时工作(realtime task) 其实并不是 一个 Linux 的行程，而是一个 Linux 的可加载式核心模块( loadable kernel module)。
之所以要如此做的原因在于 Linux 是一个很大的系统，且在设计的时候并没 有考虑 real-time 的需求。举个例说，单一个 Linux 系统呼叫可能会花上超过 10ms 的时间。对有些像工业控制的应用而言，它们对时间的要求通常在 1ms 的 等级上，Linux 根本无法满足这种需求。所以 NMT RT-Linux 采用一个比较简单 的做法，它干脆不用直接 Linux 的任何功能，而把需要高度时间精确度的工作 写成一个驱动程序的型式，然后直接用 PC 时序芯片 (timer chip) 所产生的中 断呼叫这个驱动程序。如此一来，不管 Linux 系统呼叫的时间有多长都没有关系 了。
从这个角度看，NMT RT-Linux 其实是一个实时驱动程序的架构，算不上是真 正的 real-time Linux. 但由于它出现的早，且其架构很符合自动控制的需求。 使用者非常的多，且多半是有关自动控制的应用。
RTAI
RTAI 是 Real-Time Application Interface 的缩写。顾名思义知道它是一套可 以用来写实时应用程序的界面。大致而言，RTAI 和 NMT RT-Linux 是相同的东西。 它同样的架空了 Linux，而直接用可加载式核心模块( loadable kernel module) 实作 real-time process。每一个实时行程实际上就是一个可加载式核心模块。
RTAI 和 NMT RT-Linux 最大的不同地方在于它非常小心的在 Linux 上定义了 一组 RTHAL (Real-Time Hardware Abstraction Layer)。RTHAL 将 RTAI 需要 在 Linux 中修改的部份定义成一组程序界面，RTAI 只使用这组界面和 Linux 沟通。这样做的好处在于我们可以将直接修改 Linux 核心的程序代码减至最小， 这使得将 RTHAL 移植到新版 Linux 的工作量减至最低。
RTAI 采取这种途径最大的原因在于 NMT RT-Linux 在由 2.0 版移植至 2.2 版 的过程序遇到问题，使得基于 2.2 版核心的 NMT RT-Linux 一直无法完成。所以 在 Dipartimento di Ingegneria Aerospaziale Politecnico di Milano 的 Paolo Mantegazza 和他的同事们就决定自行做移植的工作，但由 NMT RT-Linux 的困境他们体认到必须采取上述的途径以解决将来可能再度面临的兼容性问题。
于是 RTAI 便诞生了，它是一个比 NMT RT-Linux 更好的 NMT RT-Linux，虽 然后来 NMT RT-Linux 也随后完成移植的工作，但那已经是 RTAI 诞生半年以 后的事了。
LXRT
由于 RTAI 无法直接使用 Linux 的系统呼叫，解决的方法是使用 RT-FIFO 将一个 RTAI real-time kernel module 和真正的 Linux 行程连接在一起，由这个行程做 代理人的工作为其呼叫 Linux 系统呼叫。下图说明了 LXRT proxy 行程的概念
红色的部份表示一组 RTAI 的实时行程和它在使用者模式 (user space) 的 伙伴。你可以了解，当 proxy 激活后，它不再可以被任何的抢先 (preempt)， 所以原本有的优势就不再保有了。
KURT
KURT 是由 kansas 大学所创造的系统，它和 NMT RT-Linux 及 RTAI 有很大的不同。KURT 是第一个可以使用系统呼叫的 real-time Linux。由于 KURT只是简单的将 Linux 的排程器用一个很简单的时间驱动式(time driven)排程器加以取代，实时行程的执行很容易很其它非实时行程的影响。
RED-Linux
这是小弟在下不才我在加州大学 Irvine 分校所做的系统，它和 KURT 类似，是一个 可以使用所以 Linux 系统呼叫的 real-time Linux。它的特点是使用”抢先检查点 (preemption point)”改善系统的反应速度。前面说过 KURT 的最大问题在于它受 限于原有的 Linux 架构，使得系统的反应时间很难控制。然而在 RED-Linux 这一 点已经被大大的改善，由在 2.0 版的经验得知其反应延迟约在 100 us 左右。
RED-Linux 非常有弹性的排程器架构也是其特点之一，这部份基本上就是我博士 论文的主轴。它使得 RED-Linux 可以符合各种不同复杂度系统的需求。基本上，它将排程器分成 dispartcher 和 allocator 二部份，dispatcher 在核心中执行而 allocator 在使用者模式执行。allocator 可以是应用程序的一部份，也可以是一个独立的单位。通常它可能是 middleware 的一部份，负责将应用程序的 resource request 转换成 kerner 可以了解的格式。
RED-Linux 目前正在进行 POSIX 兼容模式的移植工作，所有 POSIX 中的实时 排程、定时器、sporadic server 等都将会被实作出来。
所有这些有关 real-time Linux 的计画都是在 open source 的情况下发展，所以 我们可以预期在将来它们会有某些程度上截长补短的情况出现。前面说过，real-time Linux 主要有二个大类。第一种是 NMT RT-Linux 和 RTAI，它们的实时行程实际上 是一个核心模块。所以它们事实上是一种 real-time 驱动程序，RTAI 和档案系统 及网络系统其实有很相似的结构，差别只是在于其驱动的硬件类别不同而已。
而另一方面，如 KURT, Linux/RK 及 RED-Linux 之类的系统则受限于能达到的时 间分辨率。虽然 RED-Linux 已经把这个极限推到 1ms 左右，但我们可以预期在 PC 的架构下要达到 100us 以下是很困难的。也就是说，对于要求 10K 以上频率的应用 是不可能使用这种架构来达成。
但这其实是一个很合理的限制，我们可以将二种架构整合成一个系统来满足 所有的需求。LXRT 是一个正确的方向，但如果使用 RED-Linux 和 RTAI 整合 可能更能达成需求。RED-Linux 非常弹性的排程器架构使得整合更行简单。我 希望能在未来半年内推出这个产品，以成为一个终极的 real-time Linux。并 思考如何使整个系统正式的和 Linux 整合以利未来的发展。
摘自：http://linuxfab.cx