1. 实时操作系统概述
1.1 硬实时与软实时的区别
实时操作系统（RTOS）的核心在于其可预测性，即系统必须在规定的时间约束内完成指定的任务。根据对时间约束违反的容忍程度，实时系统分为硬实时与软实时两大类。
| 特性 | 硬实时 (Hard Real-Time) | 软实时 (Soft Real-Time) |
|---|---|---|
| 截止时间违反后果 | 系统灾难或完全失效 | 性能下降，但系统仍可运行 |
| 确定性要求 | 必须100%保证在最坏情况下满足截止时间 | 统计意义上满足截止时间即可（如99.9%） |
| 典型应用 | 汽车引擎控制、飞行控制系统、医疗起搏器 | 音视频播放、网络数据包处理、人机交互 |
| 调度策略 | 优先级抢占 + 资源预留 | 优先级调度 + 尽力而为 |
| 抖动容忍度 | 微秒级抖动不可接受 | 毫秒级抖动可接受 |
关键指标：硬实时系统的最大延迟（最坏情况执行时间 WCET）是设计时的硬约束；软实时系统关注平均延迟和延迟分布。
1.2 Linux 实时性挑战
Linux 最初设计为通用分时操作系统，其内核设计哲学（吞吐量优先、公平调度）与实时系统需求存在根本性冲突。主要挑战集中在以下方面：
- 中断不可抢占：Linux 内核在中断上下文中执行时，禁止调度器切换任务。高优先级实时任务必须等待中断处理完成才能获得 CPU。
- 自旋锁与关抢占：内核中广泛使用自旋锁（spinlock）保护临界区。持有自旋锁时，CPU 处于忙等状态且禁止抢占，导致实时任务延迟不可控。
- 中断线程化缺失：传统 Linux 中断处理程序运行在不可抢占的上下文，无法被高优先级实时任务打断。
- 调度器延迟：CFS（完全公平调度器）的调度粒度以毫秒计，且调度点分布不均匀，无法满足微秒级实时需求。
- 优先级反转：低优先级任务持有高优先级任务所需的资源时，高优先级任务被阻塞，导致优先级反转问题。
典型场景：一个运行 Linux 的工业机器人控制器，当网卡中断处理程序占用 CPU 长达 500μs 时，电机控制环路（要求 100μs 周期）将错过截止时间，导致机械臂抖动。
1.3 PREEMPT_RT 项目背景与目标
PREEMPT_RT（Real-Time Linux）项目由 Thomas Gleixner、Ingo Molnar 等内核开发者于 2005 年发起，旨在将 Linux 内核改造为满足硬实时需求的通用操作系统内核。该项目通过一系列补丁集，逐步将 Linux 内核的关抢占区域缩小到可预测的微秒级。
项目背景
- 工业需求驱动：工业自动化、机器人、航空航天等领域需要兼具 Linux 生态（驱动、网络、文件系统）和硬实时能力的操作系统。
- 社区共识：早期双内核方案（如 RTAI、Xenomai）存在维护成本高、API 不兼容等问题，社区逐渐转向单内核 PREEMPT_RT 方案。
- 上游化进程：PREEMPT_RT 补丁从 2005 年起持续向上游 Linux 内核合并，截至 Linux 6.x 版本，大部分核心机制已合入主线。
核心目标
| 目标 | 实现手段 | 预期效果 |
|---|---|---|
| 中断线程化 | 将中断处理程序下半部改为可抢占的内核线程 | 高优先级实时任务可抢占中断线程 |
| 自旋锁可抢占 | 将自旋锁替换为可睡眠的互斥锁（rt_mutex） | 持有锁时允许抢占，降低延迟 |
| 优先级继承 | 实现优先级继承协议，解决优先级反转 | 高优先级任务不被低优先级任务无限阻塞 |
| 高精度定时器 | 使用 hrtimer 替代传统定时器 | 定时精度从 jiffy（毫秒级）提升到纳秒级 |
| 关抢占区域最小化 | 逐行审查内核代码，减少 preempt_disable 区域 | 最大关抢占时间 < 200μs |
注意：PREEMPT_RT 并非万能方案。它无法解决硬件本身的中断延迟（如慢速总线、共享中断线），也无法弥补应用程序设计中的优先级反转问题。硬件平台的中断控制器适配是 PREEMPT_RT 落地的关键环节。
PREEMPT_RT 的实时性指标
经过 PREEMPT_RT 补丁优化后的 Linux 内核，在 x86 和 ARM 平台上可达到以下实时性能：
- 中断响应延迟： < 50μs（典型值 10~30μs）
- 任务切换延迟： < 100μs（典型值 20~50μs）
- 最大关抢占时间： < 200μs（经过硬件中断控制器适配优化后）
- 定时器精度： 纳秒级（依赖硬件高精度定时器支持）