提高实时操作系统的实时性能和可靠性策略
在设计工业控制系统或医疗设备时，大部分工程师和系统设计工程师会认为采用RTOS是必需的。然而，网际路由器、车载娱乐系统和多媒体设备等普通应用还需要采用RTOS吗？像Linux或Windows这样的通用操作系统是否就能胜任呢？通常，这些产品需要采用RTOS，但是这个问题经常直到设计阶段的后期才能意识到。
RTOS对于很多嵌入式系统来说不但是有益的，而且也是必要的，熟悉到这一点很重要。例如，一个播放如MPEG格式电影的设备，假如依靠软件来实现其整个内容传输，可能会出现用户难以接受的高丢帧率。然而，通过使用RTOS，系统设计工程师能够准确地控制软件过程的执行顺序，从而保证按照给定的媒体速率进行播放。上述大部分情况适用于用户希望对输入做出立即响应的系统。通过RTOS，开发人员能够保证由用户的操作总能得到及时的响应，除非一个更重要的操作必须首先执行。
总之，一个好的RTOS支持开发人员控制系统执行任何任务或对任何重要事件做出反应的时间，并且能够以一种可以猜测并且完全一致的形式满足任务执行的最终期限要求。但是，假如RTOS崩溃，这些最终期限就不能被满足。因此，RTOS必须提供高度的可靠性。非凡是它必须提供在不需要重启的情况下，从软件故障中快速并智能恢复的机制。
抢占式调度
在像Linux这样的通用操作系统中，在对线程和进程的CPU占用上采用了“公平”调度策略。这样的策略能够提供良好的整体表现，但是不能保证高优先级、对时间要求严格的线程将优先于低优先级的线程执行。事实上，操作系统有时甚至会中断高优先级的线程来为低优先级线程提供CPU时间。其结果可能造成对时间要求严格的线程很轻易地错过它们的最终期限，甚至在一个高速的高端处理器上运行时也会出现这种情况。
而在RTOS中，线程按照其优先级顺序执行。假如一个高优先级的线程预备运行时，它将在一个短的、有限时间间隔内从任何可能正在运行的低优先级进程接管CPU。另外，高优先级的线程能够不被中断地运行，直到它已经完成了需要做的事情－当然是在不被更高优先级进程抢占的前提下。这种方法就是抢占式调度，保证了高优先级线程始终满足其最终期限，而不管有多少其它线程正在竞争CPU时间。
通过合理地控制线程优先级，开发者能显著地提高很多对用户非常重要的应用响应速度。然而，控制优先级可能是一把双刃剑，当使用不当时它可能会潜在地导致低优先级的进程不能得到CPU时间。保证高优先级的进程和线程的同时确保不会使其它进程处于“饥饿”状态的关键是要对它们的执行进行限制，通过对执行进行调整或在响应加载的过程中进行控制，开发人员能够限制这些活动消耗的CPU时间比例，并支持低优先级进程获得对CPU的共享。
优先级控制能够使很多应用受益，包括像前面提到的媒体播放器。媒体播放器需要实现正常播放所要求的速率。在这种限制之下，一个读线程和一个显示线程可以被设计成依靠一个可编程的定时器来唤醒，缓冲或显示一帧后进入睡眠状态，直到下一个定时触发。这提供了一种调整机制，支持高于正常用户活动而又低于关键系统功能的优先级设置。换句话说，假如没有更重要的任务预备运行，媒体播放将始终以给定的媒体速率执行。
最坏情形
抢占式调度仅在高优先级的线程在一个短的、有限时间段内抢占低优先级线程的情况下有效。否则，系统将不可能猜测要花费多长时间来执行一个给定的操作。因此，任何销售进程模式的RTOS的供给商都必须提供针对下面两种时间间隔提供最坏情形：线程切换时间，即当两个线程处于同一进程的情况下，从执行一个线程的最后一条指令到执行下一个被调度线程的第一条指令所经过的时间；前后关系切换时间，其定义同上，但仅针对两个线程处于不同进程的情况。
可以将线程看作是最小的“执行单元”，而将进程看作是一个或多个线程的“容器”，进程定义了线程将要在其中执行的地址空间。显然，最坏情形的前后关系切换时间将比最坏情形的线程切换时间要慢，尽管在一个好的RTOS设计中差别可能是微不足道的。
将所有的线程放在几个大的进程中将是错误的，因为线程提供的切换速度更快。虽然线程能实现并行处理优势因而适合于某些设计，但将一个应用分成多个内存保护的进程使得代码更轻易调试，提供了更好的错误隔离和恢复能力，并答应系统进行新功能的动态升级。
评论