阅读前言
本文以QNX系统官方的文档英文原版资料为参考，翻译和逐句校对后，对QNX操作系统的相关概念进行了深度整理，旨在帮助想要了解QNX的读者及开发者可以快速阅读，而不必查看晦涩难懂的英文原文，这些文章将会作为一个或多个系列进行发布，从遵从原文的翻译，到针对某些重要概念的穿插引入，以及再到各个重要专题的梳理，大致分为这三个层次部分，分不同的文章进行发布，依据这样的原则进行组织，读者可以更好的查找和理解。
1. 什么是实时，为什么我需要它？
实时性是操作系统中一个常常被误解且误用的特性。本附录概述了实时计算的一些关键要素，并讨论了一些设计考量因素及优势。
我们可以从 comp.realtime 新闻组常见问题解答（FAQ）中对实时系统的基本定义开始说起：
实时系统是这样一种系统，其计算的正确性不仅取决于计算的逻辑正确性，还取决于产生结果的时间。如果系统的时间约束未得到满足，就可以说发生了系统故障。
那么，实时性就是系统中时间确实 “至关重要” 的一种特性。在实时系统中，计算的价值取决于答案的及时性。例如，延迟完成的计算其价值会降低，甚至毫无价值，而提前完成的计算也不会有额外价值。实时性始终是一个程度问题，因为即使是批处理计算系统也具有实时性方面的考量 —— 毕竟没人希望自己的工资到账延迟两周！
当系统中存在资源竞争，且资源由众多活动共享时，问题就会出现，而这正是我们将实时性特性应用于操作系统的背景。在实现任何实时系统时，该过程中的一个关键步骤是确定活动的调度计划，以确保所有活动都能按时完成。
任何实时系统都包含不同类型的活动：
- 可调度的活动；
- 不可调度的活动，例如操作系统设施和中断处理程序；
- 非实时活动。
如果不可调度的活动能够优先于可调度的活动执行，它们将会影响系统处理时间约束的能力。
硬实时和软实时
硬实时是系统中计算及时性的一种特性。系统中的硬实时约束意味着，如果计算延迟完成，那么该计算就毫无价值，而且计算延迟可能会对系统造成灾难性的后果。简而言之，硬实时系统就是所有活动都必须按时完成的系统。
软实时是计算及时性的一种特性，在此情况下，计算的价值会随着其延迟程度而降低。软实时系统能够容忍软实时计算的一些延迟结果，只要其价值尚未降至零。软实时系统通常带有一些衍生要求，例如关于可接受的计算延迟频率的随机模型。需要注意的是，这与该术语的常规用法大不相同，常规用法并不考虑计算完成得多晚或者这种情况发生的频率。
软实时常常被不恰当地应用于那些不满足确保计算能够按时完成的必要条件的操作系统。这类操作系统最好被描述为准实时或伪实时操作系统，因为它们在必要时会优先执行实时活动，但却没有充分考虑系统中的不可调度活动。
谁需要实时性？
传统上，实时操作系统一直用于需要硬实时能力的 “关键任务” 环境中，在这种环境下，如果不能及时执行活动，可能会对人员或财产造成损害。
然而，常常被忽视的情况是，在需要满足服务质量保证的场景中也需要实时性，特别是当无法满足要求时可能会导致经济处罚。这涵盖了一些明显的服务场景，例如 “三十分钟内送达，否则免费”，但也包括一些无形的损失，比如失去机会或市场份额下降。
越来越多的消费类设备也开始采用实时性技术，这些复杂的系统对可靠性有着极高的要求。例如，一个旨在播放实时视频（如 MPEG 影片）的非实时设备，如果其内容传输的任何部分依赖于软件，那么它可能会出现丢帧现象，且丢帧速率可能会让用户觉得无法接受。
在设计系统时，开发人员需要评估性能优势是否值得使用实时技术。早期做出的决策可能会产生意想不到的后果，例如当已部署系统过载时，可能会出现病态行为，导致大多数活动甚至所有活动都无法按时完成（如果能完成的话）。
实时技术可以通过改善对某些事件的感知响应，或者确保重要活动相对于系统中的其他活动优先执行等方式，应用于常规系统，从而对用户体验产生积极影响。
什么是实时操作系统（RTOS）？
我们对构成硬实时操作系统的定义基于与行业实践相符的实时调度理论：
硬实时操作系统必须保证，在不考虑外部因素的情况下，如果具备足够的计算能力，就能执行可行的调度计划。在此语境下，外部因素指的是可能产生中断的设备，包括会因网络流量而产生中断的网络接口。
换句话说，如果系统设计者能够控制系统环境，那么操作系统本身不会成为任何计算延迟的原因。我们可以将这个术语应用于常规操作系统（这类操作系统通常根据任务优先级来执行任务），通过参考调度理论并推导出必须满足的一组最低条件来实现。不深入细节的话，调度理论表明，可以通过将可用时间划分为周期性的时段，并假设每个时段的一定比例预留给特定的实时活动，从而将调度计划转换为静态优先级分配，以此保证及时性。
为了做到这一点，必须满足以下基本要求：
- 高优先级任务总是优先于低优先级任务执行。
- 优先级反转（当高优先级任务需要低优先级任务所分配的资源时可能会出现这种情况）是有界的。
- 不可调度的活动，包括非实时活动和操作系统活动，在任何特定时段内都不会超出剩余容量。
由于条件 3 的存在，我们必须排除那些不受操作系统控制的活动，这就引出了上述关于外部因素的规定。
然后我们可以推导出以下操作系统要求（OSRs）：
- 操作系统必须支持对任务（适用于线程和进程）进行固定优先级抢占式调度。
- 操作系统必须为同步原语提供优先级继承或优先级天花板模拟机制。
- 操作系统内核必须是可抢占的。
- 中断必须有固定的延迟上限。进一步来说，需要支持嵌套中断。
- 操作系统服务必须按照服务客户端所确定的优先级来执行：
-
- 它所依赖的所有服务都必须继承该优先级。
- 必须对服务所使用的所有共享资源应用优先级反转避免机制。
OSR 3 和 OSR 4 对任何特定实时活动开始时所产生的延迟施加了固定的上限。OSR 5 确保操作系统服务本身（作为内部因素）不会向系统中引入可能违反基本要求 3 的不可调度活动。
实时操作系统（RTOS）与常规操作系统有何不同？
将实时操作系统（RTOS）与常规操作系统区分开来的关键特性是上述所有要求中所固有的可预测性。常规操作系统（如 Linux）在将线程和进程调度到 CPU 时试图采用 “公平性” 策略。这使得系统中的所有应用程序都有机会取得进展，但并没有确立实时线程在系统中的优势地位，也没有像保证它们按时完成任务所要求的那样保留其相对优先级。同样，当代表客户端线程执行通常在内核调用中执行的系统服务时，通常所有优先级信息都会丢失。这会导致不可预测的延迟，从而使活动无法按时完成。
相比之下，QNX Neutrino 实时操作系统（RTOS）中使用的微内核架构旨在直接应对所有这些要求。
微内核本身只是管理系统内的线程，并允许它们相互通信。调度始终在线程级别进行，并且线程总是根据其固定优先级进行调度 —— 或者，在出现优先级反转的情况下，由微内核根据优先级反转情况进行调整后的优先级来调度。准备运行的高优先级线程可以抢占低优先级线程。
在这个框架内，除了基本的调度和进程间通信（IPC）之外，所有设备驱动程序和操作系统服务都作为系统中的独立进程存在。所有服务都通过同步消息传递 IPC 机制进行访问，该机制允许接收方继承客户端的优先级。这种优先级继承方案通过将原始实时活动的优先级传递到所有服务请求以及后续的设备驱动程序请求中，从而满足了 OSR 5 的要求。
同时也具备相应的灵活性。由于 OSR 1 和 OSR 5 强调设备驱动程序请求需要按照客户端的优先级顺序进行操作，正常操作的吞吐量可能会大幅降低。利用这种模式，可以将一个操作系统服务或设备驱动程序替换为满足这些要求的实时版本。复杂系统通常会将此类资源划分为实时和非实时两部分，针对每种资源采用不同的服务和设备驱动程序实现方式。
正因如此，系统中的所有活动都是按照代表其执行的线程所确定的优先级来执行的。
什么是软实时操作系统？
软实时操作系统必须能够有效地完成硬实时操作系统所必须做的一切。此外，软实时操作系统还必须具备对系统中任务进行精确成本核算的监控能力。它必须确定活动何时未能按时完成或者何时超出了其分配的 CPU 容量，并触发相应的响应。
这一切对我的应用程序有什么影响？
如果您正在编写一个要部署在实时操作系统上的应用程序或系统，考虑实时操作系统的特性对应用程序执行的影响，并了解如何利用这些特性使其对您有利是很重要的。例如，借助实时操作系统，您可以提高用户发起的某些操作的响应速度。
大多数应用程序通常在系统内以默认的用户优先级运行。这意味着应用程序通常以循环轮转的方式执行，彼此竞争一定比例的 CPU 容量。如果没有上述提到的那种实时调度机制，您可以调整系统中进程的优先级，使某些活动相对于系统中的其他活动优先执行。调整优先级是一把双刃剑。谨慎使用的话，它可以极大地提高对用户来说重要的方面的响应速度。同时，也有可能导致系统中的其他进程缺乏资源，而这种情况在常规桌面系统中通常是不会发生的。
确保高优先级进程和线程不会使系统中的其他进程缺乏资源的关键在于确定对它们执行所施加的限制。通过控制执行节奏，或者根据负载进行限制，您可以限制这些活动所消耗的 CPU 比例，以便用户进程能够获得它们应得的 CPU 份额。
媒体播放器（如音频播放器（MP3、.wav 等）和视频播放器（MPEG - 2））就是能够从优先级调整中获益的应用程序的好例子。媒体播放器的操作可以与正确播放所需的媒体速率相挂钩（例如，44kHz 音频、30fps 视频）。因此，在这个限制条件下，用于缓冲数据的读取线程和用于渲染或播放的线程都可以设计为根据可编程定时器唤醒，缓冲或渲染一帧数据，然后进入睡眠状态等待下一个定时器触发。这样就提供了必要的节奏控制，使得可以将优先级分配得高于正常用户活动，但低于更关键的系统功能。
通过选择合适的优先级，您可以确保播放能够始终以给定的媒体速率稳定进行。一个编写良好的媒体播放器还会考虑服务质量，这样如果它没有获得足够的 CPU 时间，它可以通过有选择地丢弃样本或遵循适当的回退策略来降低自身需求。这样也就防止了它使其他进程缺乏资源。
您可能还希望在系统中优先处理某些用户事件。当您增加应用程序内的并发程度，并且事件总能在可预测的短时间内得到处理时，这种做法效果很好。这里的关键问题在于这些事件产生的频率。如果它们不会过于频繁地发生，那么提高响应这些事件的线程的优先级就是安全的。如果它们可能过于频繁地发生，那么在过载情况下其他活动就会缺乏资源。
最简单的解决方案是将事件处理责任划分到具有不同优先级的不同处理线程中，并对请求进行排队或通过消息传递来交付请求。您可以将处理程序的执行与定时器绑定，这样线程的执行就会受到定时器的限制，在给定的时间间隔内处理固定数量的请求。这凸显了划分应用程序责任区域的重要性，它提供了一种灵活的设计，为有效利用并发和优先响应创造了机会，所有这些都有助于提升响应的直观感受。
2. 理解总结
这段内容围绕实时操作系统（RTOS）这一核心主题，从多个方面进行了深入且全面的阐述，包括实时性的概念、不同类型实时系统（硬实时、软实时）的特点、谁需要实时性、实时操作系统的定义及要求、与常规操作系统的区别，以及实时操作系统对应用程序的影响等，旨在帮助读者清晰理解实时操作系统相关的诸多关键知识点以及如何在实际应用中合理运用。
实时性概念及相关活动类型
首先介绍了实时性在操作系统领域常被误解和误用的现状，引出实时系统的基本定义，强调时间对计算结果正确性的重要性，说明了实时性是个程度问题且在各类系统中都有体现。接着阐述实时系统包含的不同活动类型，指出不可调度活动若优先执行会影响系统处理时间约束的能力，为后续进一步探讨不同实时特性的系统做铺垫。
硬实时和软实时系统特点
详细区分了硬实时和软实时的概念，硬实时要求所有活动必须按时完成，计算延迟后果严重；软实时则允许一定程度的计算延迟，只要价值未降为零，且还提及软实时概念常被误用的情况，帮助读者准确把握这两种不同实时特性系统的本质区别。
实时性的应用场景及需求
从多个角度探讨了谁需要实时性，既包括传统关键任务环境，也涵盖需满足服务质量保证的场景以及消费类设备等，强调在设计系统时要权衡使用实时技术的利弊，因为不当使用可能在系统过载时出现问题，但合理应用能提升用户体验，展示了实时性在不同领域的重要性和应用的复杂性。
实时操作系统的定义及要求
基于实时调度理论给出硬实时操作系统的定义，明确其必须满足的一系列基本要求以及推导出的操作系统要求（OSRs），这些要求从调度方式、优先级处理、内核特性到中断管理以及操作系统服务执行等多方面进行了规范，旨在保证系统的可预测性和实时性，是理解硬实时操作系统的核心内容。
实时操作系统与常规操作系统的区别
对比分析了 RTOS 和常规操作系统（如 Linux）的关键差异，指出常规操作系统采用 “公平性” 调度策略导致无法保证实时线程按时完成任务，而 QNX Neutrino RTOS 的微内核架构通过特定的线程调度、优先级管理以及服务访问机制等，能直接应对实时性相关要求，并且具备灵活性，可根据需求调整资源分配方式，凸显了 RTOS 在实时性保障方面的独特优势。
软实时操作系统的额外要求
说明软实时操作系统除具备硬实时操作系统的功能外，还需具备对任务的监控和成本核算能力，能对活动未按时或超出资源分配情况做出响应，进一步完善了对不同类型实时操作系统特性的介绍。
实时操作系统对应用程序的影响
最后着重讲述了实时操作系统特性如何影响应用程序，以媒体播放器为例说明了通过合理调整优先级、控制执行节奏、考虑服务质量以及划分事件处理责任等方式，既能提高应用程序中关键操作的响应速度，又能避免高优先级任务过度占用资源影响其他进程，体现了在实际应用中利用实时操作系统特性的技巧和重要性，为开发者在编写基于实时操作系统的应用程序时提供了实用的指导思路。
总体而言，这段内容构建起了一个较为完整的关于实时操作系统的知识体系，从理论概念到实际应用，全方位地帮助读者深入理解实时操作系统及其相关的诸多重要方面。
