1. 实时系统概述
1.1 实时系统的定义
实时系统（Real-Time System）是指系统必须在严格的时间约束内对外部事件做出响应的计算系统。其核心特征在于：计算的正确性不仅取决于逻辑结果，还取决于结果产生的时间。如果响应时间超过了预设的截止时间（Deadline），即使逻辑结果正确，系统也被视为失效。
关键概念：实时性 ≠ 快速性。实时系统追求的是“可预测的确定性响应”，而非单纯的“高吞吐量”。一个 1ms 响应但抖动（Jitter）达 500μs 的系统，可能比一个 10ms 响应但抖动仅 10μs 的系统更不适合硬实时场景。
实时系统的三大要素：
- 时间约束（Timing Constraint）：每个任务都有明确的截止时间。
- 确定性（Determinism）：系统行为在时间维度上是可预测的。
- 可靠性（Reliability）：在极端负载下仍能保证时间约束。
1.2 硬实时与软实时的区别
根据错过截止时间（Deadline Miss）对系统的影响程度，实时系统分为硬实时（Hard Real-Time）和软实时（Soft Real-Time）两大类。
| 对比维度 | 硬实时（Hard RT） | 软实时（Soft RT） |
|---|---|---|
| Deadline 错过后果 | 系统灾难或完全失效 | 性能下降，但系统可继续运行 |
| 典型场景 | 航空电子、汽车引擎控制、医疗起搏器 | 音视频播放、网络路由、人机交互 |
| 时间确定性要求 | 必须 100% 保证最坏情况响应时间 | 统计意义上满足即可（如 99% 满足） |
| 调度策略 | 优先级抢占 + 资源预留 | 优先级调度 + 尽力而为 |
| 抖动容忍度 | 极低（μs 级） | 较高（ms 级） |
| 典型 RTOS | VxWorks、QNX Neutrino | Linux (PREEMPT_RT)、FreeRTOS |
常见误区：不要将“硬实时”等同于“高频率”。一个 1kHz 的控制回路如果允许偶尔丢帧，可能仍是软实时；而一个 10Hz 的安全联锁系统，如果任何一次响应超时都会导致设备损坏，则属于硬实时。
1.3 实时操作系统（RTOS）与通用操作系统（GPOS）对比
实时操作系统（RTOS）与通用操作系统（GPOS）在设计哲学、调度策略、中断处理等方面存在本质差异。理解这些差异是正确选择和使用 PREEMPT_RT 补丁的前提。
| 对比维度 | RTOS（如 VxWorks、QNX） | GPOS（如标准 Linux、Windows） |
|---|---|---|
| 设计目标 | 可预测的实时响应 | 高平均吞吐量、公平调度 |
| 调度策略 | 优先级抢占（固定/动态优先级） | CFS（完全公平调度）、时间片轮转 |
| 中断延迟 | 极低（μs 级），可预测 | 较高（ms 级），受关中断影响 |
| 内核抢占性 | 完全可抢占（内核态可被中断） | 有限抢占（内核态不可抢占） |
| 锁机制 | 优先级继承/天花板协议 | 自旋锁、互斥锁（可能优先级反转） |
| 内存管理 | 静态分配为主，避免缺页 | 虚拟内存、按需分页、Swap |
| 抖动（Jitter） | 极低（μs 级） | 较高（ms 级，不稳定） |
| 典型应用 | 工业控制、航空航天、汽车 ECU | 桌面、服务器、云计算 |
核心差异总结：
- 调度哲学：RTOS 追求“谁最紧急谁先执行”；GPOS 追求“谁等待最久谁先执行”。
- 内核抢占：RTOS 内核态可被高优先级任务抢占；GPOS 内核态通常不可抢占（PREEMPT_RT 补丁正是为了解决此问题）。
- 资源管理：RTOS 倾向于静态预留；GPOS 倾向于动态共享。
1.4 为什么选择 PREEMPT_RT 方案
在工业控制、机器人、自动驾驶等领域，既需要 Linux 丰富的生态（驱动、网络、文件系统），又需要 RTOS 级别的实时性。PREEMPT_RT 补丁正是为了弥合这一鸿沟而诞生：
- 生态兼容性：保留标准 Linux 内核 API、驱动框架和用户空间工具。
- 实时性能：将内核中断延迟从 ms 级降低到数十 μs 级。
- 社区支持：由 Linux 基金会维护，已逐步合入主线内核。
- 成本优势：无需购买商业 RTOS 许可证，基于开源社区。
学习路线提示：本章是后续所有章节的基础。理解硬实时与软实时的区别，以及 RTOS 与 GPOS 的架构差异，将帮助你更好地理解 PREEMPT_RT 补丁在 Linux 内核中做了哪些关键改造（如中断线程化、自旋锁替换、优先级继承等）。