2. 实时系统基础

在 RTOS 中断与实时性能优化中，所有优化动作最终都要落到一组可度量的实时指标上。如果只谈“响应快”“不卡顿”，就无法判断系统是否真正满足实时约束。本节围绕硬实时与软实时、确定性、抖动、延迟、吞吐量、优先级反转等基本术语展开，建立后续章节分析中断延迟、调度策略和性能优化的共同语言。

一、硬实时与软实时：约束强度不同

实时并不等于“速度快”，而是指系统必须在规定时间内给出正确结果。根据错过截止时间的后果，实时任务通常分为硬实时和软实时。

• 硬实时：任务必须在截止时间前完成，否则视为系统失败。例如电机换相控制、安全气囊触发、刹车防抱死控制。错过一次截止时间可能造成设备损坏、人身伤害或不可恢复的错误。
• 软实时：任务偶尔超时只会降低服务质量，不会造成灾难性后果。例如音视频播放、界面刷新、传感器数据展示。超时表现为卡顿、花屏、延迟增大，但系统仍可继续运行。
• 准实时/固实时：介于两者之间，偶尔超时结果仍可用，但价值明显下降。例如工业数据采集，晚到的数据仍可记录，但可能影响控制决策的时效性。

判断一个系统属于哪一类，不能只看任务本身，还要看截止时间、超时后果和可恢复性。同一个温度采集任务，用于趋势显示时是软实时；用于过热保护切断电源时就是硬实时。

二、确定性、抖动、延迟与吞吐量

实时系统的评价指标不是单一维度，而是由确定性、延迟、抖动、吞吐量等共同构成。

• 确定性：系统在最坏情况下仍能在可预测的时间内完成响应。确定性强调“最坏情况可界定”，而不是“平均很快”。
• 延迟：从事件发生到系统产生响应之间的时间。中断延迟、调度延迟、任务执行时间都会叠加到总延迟中。
• 抖动：同一类响应时间的波动范围。若某中断响应时间在 8μs 到 12μs 之间波动，抖动为 4μs。抖动越小，控制周期越稳定。
• 吞吐量：单位时间内系统能处理的任务、事件或数据量。吞吐量高不一定实时性好，因为高吞吐可能以增大延迟和抖动为代价。

例如，一个系统平均中断延迟为 5μs，但最坏情况达到 200μs；另一个系统平均延迟为 10μs，最坏情况只有 15μs。对于硬实时系统，后者往往更可取，因为它的确定性更好。

三、关键指标关系与度量方法

下面用一张关系图展示事件从发生到任务完成的过程中，各类延迟和抖动的来源。该图不是普通流程图，而是信号链与时间轴结合的性能分解图。

从图中可以看出，总响应时间由多个环节叠加而成。优化时不能只盯着 CPU 主频，还要关注关中断时间、调度器开销、临界区长度和资源竞争。

四、优先级反转：实时系统中的经典风险

优先级反转是指高优先级任务因为等待低优先级任务释放共享资源，而被中优先级任务间接阻塞的现象。它本身不是错误，但如果处理不当，会让高优先级任务的响应时间变得不可预测，破坏确定性。

典型场景如下：

1. 低优先级任务 L 先获得互斥量，进入临界区。
2. 高优先级任务 H 就绪，需要同一互斥量，于是被阻塞。
3. 中优先级任务 M 就绪并抢占 L。
4. L 无法运行，无法释放互斥量，H 只能继续等待。
5. 结果：H 被 M 间接拖延，系统最坏响应时间被放大。

常见解决方法是优先级继承和优先级天花板。优先级继承让低优先级任务在持有互斥量期间临时提升到等待它的最高优先级，从而减少被中优先级任务抢占的时间。优先级天花板则为互斥量预设一个天花板优先级，任务获得该互斥量时直接提升到天花板优先级。

/* 伪代码：优先级继承示意 */
低优先级任务 L：
    mutex_lock(&m);        // 持有互斥量
    /* 临界区 */
    mutex_unlock(&m);

高优先级任务 H：
    mutex_lock(&m);        // 若 L 持有，则 H 阻塞
    /* 使用共享资源 */
    mutex_unlock(&m);

/* 当 H 等待 m 时，L 临时继承 H 的优先级，
   避免被中优先级任务 M 抢占。 */

五、指标对比与常见误区

理解这些基础术语后，后续分析中断延迟、临界区、调度策略和优先级配置时，就能用统一的指标判断优化是否真正有效，而不是被平均性能数据误导。