📚 Android 系统全景专栏 · 持续更新中

本系列把"操作系统"放回它诞生的历史场景与资源约束里,解释"为什么是这样设计的"。不是"OS 入门",是给中高级嵌入式/底层工程师做设计溯源与选型决策的深度系列。重心在嵌入式实时操作系统,通用 OS 作铺垫与对照。所有论述围绕设计思想,不堆砌寄存器与硬件细节。

👉 想系统追更，戳这里查看完整专栏：
【操作系统设计思想系列】
👉 其他技术系列专栏，欢迎关注、交流、共同成长：
【CAN 技术系列】 【SPI 技术系列】【I2C 技术系列】 【串口技术系列】【RISC-V 架构系列】【Linux内核系列】 【 Android 系统全景专栏】

---

本篇定位:L4 收官第二篇,⭐⭐⭐ 深度。⑤篇立了"实时 = 最坏情况可预测",本篇把"实时性"这个被滥用的词彻底拆清:调度理论与工程取舍。本篇讲清:
① 抢占四级阶梯(协作→抢占点→任意点→完全抢占内核),每级实时性跃升与工程代价;
② 优先级抢占为何主流(固定优先级 + RMA 可静态分析);
③ RMA(Rate Monotonic Analysis)利用率上界 69% 的数学推导与工程修正;
④ EDF 理论上界 100% 但过载雪崩的工程劣势;
⑤ 固定优先级 vs 动态优先级的工程取舍;
⑥ 临界区是实时性命门(RTOS 实时性上限 ≈ 最长关中断时间);
⑦ worst-case latency 五分量再分解;
⑧ RTOS 语境微内核重新赢(恒定开销+强隔离 vs 平均快+全崩);
⑨ "实时≠快"最终澄清。读完你能做 RMA 可调度性分析、量最长关中断时间、讲清四级抢占与临界区命门、纠正"EDF 最优所以该用 EDF"的误区。

嵌入式视角:你调 RTOS 卡住时,八成在临界区与优先级反转,不在硬件
安全核调 RTOS,任务偶尔抖动几十微秒-毫秒,八成不是硬件问题,是:
① 某处关中断过长(某驱动临界区关中断几百微秒,ISR 延迟);
② 优先级反转(信号量保护资源,高优先级被低阻塞);
③ 临界区关调度过长(vTaskSuspendAll 范围太大)。
调试第一步不是怀疑硬件,是量最长关中断时间(逻辑分析仪测 ISR 响应,或 RTOS 统计 API)+ 查原语选型(是否用信号量保护资源)。这是⑮篇对你调试的直接价值——“实时问题八成在临界区与反转”,量最长关中断是第一动作。理解四级抢占与 RMA,你才知道"我的系统最坏情况能否过 deadline"是可数学回答的,不是凭感觉。

---

---

一、调度与抢占:实时性的两个轴

1.1 调度策略 vs 抢占粒度

实时性由两个轴决定:

• 调度策略(scheduling policy):按什么规则选下一个任务(优先级/RR/EDF/协作)。
• 抢占粒度(preemption granularity):何时能抢占当前任务(协作/抢占点/任意点/完全抢占内核)。

两个轴正交——可"优先级抢占 + 任意点抢占"(FreeRTOS),可"优先级抢占 + 完全抢占内核"(VxWorks),可"EDF + 任意点"(NuttX EDF 可选)。本篇分讲两轴,再合讲实时性。

1.2 实时性的形式化回顾

⑤篇立了实时性形式化:

• 实时 ≠ 快:实时 = 最坏情况可预测(worst-case bound),不是平均快。
• jitter(抖动):响应时间的 max - min,实时要求 jitter 小。
• worst-case latency:T_max = T_sched + T_preempt + T_critical + T_dispatch + T_execute,逐项压缩到 ≤ deadline。

本篇逐项展开:T_sched/T_preempt(调度策略轴)+ T_critical(抢占粒度轴 + 临界区)+ T_dispatch/T_execute(切换与执行)。

1.3 本篇核心论点

论点:实时性是"调度策略(选谁)+ 抢占粒度(何时切)+ 临界区(切得了多久)“三者的联合函数,不是"调度算法多高级”。 工程主流选"固定优先级抢占 + 任意点抢占 + 短临界区"(FreeRTOS/μC/OS/ThreadX),因可静态分析(RMA)+ 过载可降级 + 工程简单;VxWorks/QNX 走"完全抢占内核"是因场景需内核态延迟有界(⑩⑫篇)。EDF 理论最优但过载雪崩,工程不主流。

---

二、抢占四级阶梯:协作→抢占点→任意点→完全抢占

2.1 四级阶梯

抢占粒度的四级阶梯(从低到高实时性):

级别	抢占时机	代表	实时性
① 协作式(cooperative)	任务主动 yield	早期 Mac/Windows 3.1	差(任务不让则全等)
② 抢占点(preemption points)	内核显式抢占点	早期 Linux(2.4 前)	中(抢占点间不可抢)
③ 任意点抢占(preemptive)	用户态任意点可抢	FreeRTOS/μC/OS/RT-Thread	好(用户态可抢,内核临界区不可)
④ 完全抢占内核(fully preemptible)	内核态任意点可抢	VxWorks/QNX	极好(内核态也抢)

2.2 ① 协作式

协作式(cooperative):任务主动调用 yield 让出 CPU,无强制抢占。

void task(void) {
    while (1) {
        do_work();
        yield();  /* 主动让出,其他任务才能跑 */
    }
}

• 优势:实现极简(无调度中断/无上下文切换硬件),临界区天然保护(不让则不切)。
• 劣势:非实时——某任务不让(死循环/长计算),全系统卡死。
• 代表:早期 Mac OS(9 前)/Windows 3.1/部分 IoT 协作调度。
• RTOS 不用:违背"最坏情况可预测"(任务不让 = 无上界)。

2.3 ② 抢占点

抢占点(preemption points):内核在显式位置检查"是否该调度"(如系统调用返回/中断返回)。

/* 内核路径 */
void syscall_handler(void) {
    do_syscall();
    check_preempt_point();  /* 显式抢占点,检查是否调度 */
}

• 优势:比协作式好(系统调用/中断后可切),实现比任意点简单(只在标记点检查)。
• 劣势:抢占点之间不可抢(长系统调用中途不切),延迟取决于"到下个抢占点的距离"。
• 代表:早期 Linux 2.4 前(内核非抢占,系统调用返回才调度)。
• RTOS 不主流:延迟不够低(抢占点间不可抢)。

2.4 ③ 任意点抢占(标准 RTOS)

任意点抢占(preemptive):任务在用户态任意点可被高优先级抢;内核临界区(关中断/关调度)不可抢。

• 机制:中断(SysTick/PendSV/外部中断)触发调度,中断返回时切到高优先级任务。
• 内核临界区:关中断(portDISABLE_INTERRUPTS)或关调度(vTaskSuspendAll)保护,临界区内不可抢。
• 代表:FreeRTOS/μC/OS/RT-Thread/ThreadX/NuttX/Zephyr(多数 MCU RTOS)。
• 实时性:用户态延迟 = 中断延迟 + 上下文切换(亚微秒);内核临界区延迟 = 临界区长度(取决于工程)。

这是 MCU RTOS 的主流级别——用户态任意点可抢够大多数硬实时场景(姿态控制 1ms),内核临界区靠工程保持短(几微秒)。

2.5 ④ 完全抢占内核(硬实时旗舰)

完全抢占内核(fully preemptible kernel):内核态任意点可抢(临界区极短可重入)。

• 机制:内核用细粒度锁(自旋锁/互斥锁)替代关中断,临界区极短(几条指令);中断线程化(ISR 最小,主体在可抢占内核线程)。
• 代表:VxWorks/QNX(⑩⑫篇)。
• 实时性:内核态延迟 = 当前临界区长度(极短,微秒),worst-case latency 显著降低。
• 工程代价:数量级跃升(细粒度锁+锁顺序+可重入+中断线程化),开发维护成本高。

2.6 四级的工程取舍

四级的工程取舍:

级别	实现难度	实时性	适用
协作	极低	差	非实时(早期 OS)
抢占点	低	中	通用 OS(早期 Linux)
任意点	中	好	MCU RTOS(FreeRTOS/μC/OS)
完全抢占	极高	极好	硬实时旗舰(VxWorks/QNX)

论点:从任意点(③)到完全抢占(④)是实时性的质变,但工程代价数量级跃升——FreeRTOS/μC/OS 停在③因场景(MCU + 简单任务)用③够,VxWorks/QNX 走④因场景(多核 SoC + 复杂中间件 + 极硬实时)必须。 这是⑩篇"完全抢占内核工程极限"的分级根。

2.7 Cortex-M 的任意点抢占实现

Cortex-M 的任意点抢占靠 PendSV 中断(最低优先级):

; SysTick 触发调度
SysTick_Handler:
    ; 检查是否需切换(高优先级就绪)
    ; 若需,置 PendSV
    movs r0, #0x10000000
    ldr r1, =0xE000ED04  ; ICSR
    str r0, [r1]         ; 触发 PendSV
    bx lr

; PendSV(最低优先级)做实际切换
PendSV_Handler:
    mrs r0, psp
    stmdb r0!, {r4-r11}   ; 保存
    ; 切换 TCB
    ldmia r0!, {r4-r11}   ; 恢复
    msr psp, r0
    bx lr

PendSV 最低优先级的关键:保证切换在高优先级 ISR 都退出后发生,避免栈混乱(⑥篇)。这是 Cortex-M "任意点抢占"的硬件基础——任何中断都可触发调度,PendSV 在最后做切换。

---

三、优先级抢占:固定优先级的主流地位

3.1 优先级抢占

优先级抢占(priority preemptive):每个任务有优先级,调度器选最高优先级就绪任务;高优先级就绪即抢当前。

• 固定优先级:优先级静态(编译期/启动期定),不随时间变。
• 动态优先级:优先级随时间/状态变(EDF 按 deadline,Linux CFS 按 vruntime)。

RTOS 主流用固定优先级——可静态分析(RMA),过载可预测降级。Linux CFS 是动态(vruntime),但 GPOS 不需可静态分析(优化公平非最坏情况)。

3.2 O(1) 调度器

⑤篇讲过,RTOS 用 O(1) 调度器(位图 + 就绪链表数组):

/* FreeRTOS O(1) 调度 */
UBaseType_t uxTopReadyPriority;  /* 位图,每位一优先级 */
List_t pxReadyTasksLists[configMAX_PRIORITIES];  /* 每优先级一链表 */

/* 选最高优先级 */
#define taskSELECT_HIGHEST_PRIORITY_TASK() \
    /* CLZ 找位图最高置位位 */ \
    uxTopPriority = 31 - __CLZ(uxTopReadyPriority); \
    /* 取该优先级链表头 */ \
    pxCurrentTCB = listGET_OWNER_OF_HEAD_ENTRY(pxReadyTasksLists[uxTopPriority]);

• 位图找最高优先级:CLZ(Count Leading Zeros)硬件指令,1 周期。
• 取链表头😮(1)。
• 总复杂度😮(1),不随任务数增长。

O(1) 是 RTOS 调度的硬实时根基——T_sched 分量恒定(⑤篇),不随任务数变。

3.3 同优先级 RR(时间片轮转)

同优先级多任务时,用 RR(Round Robin)时间片轮转公平:

• 每任务一个时间片(quantum,如 1ms tick)。
• 时间片用完,切到同优先级下一个任务。
• 高优先级来仍抢(优先级 > RR)。

/* FreeRTOS 同优先级 RR */
/* configUSE_TIME_SLICING = 1 时自动启用 */
/* 同优先级任务时间片轮转 */

RR 的工程意义:同优先级多任务公平(不饿死),但增加切换开销。硬实时关键路径(控制律)用单任务独占优先级(不 RR),非关键(日志/通信)用 RR 公平。

3.4 优先级抢占的过载行为

固定优先级抢占的过载行为(关键工程特性):

• 过载时低优先级饿死:CPU 不够,高优先级独占,低优先级任务饿死(不执行)。
• 可预测降级:高优先级(关键)保证 deadline,低优先级(非关键)饿死——这是"可预测降级",关键任务不受影响。
• 对照 EDF 雪崩:EDF 过载时全部错过(无降级)。

这是固定优先级主流的工程根——过载时"关键任务保,非关键饿死"是可接受的降级(系统设计时把关键任务设高优先级),EDF 过载"全崩"不可接受。

---

四、RMA:利用率上界 69%

4.1 RMA 的起源

RMA(Rate Monotonic Analysis,1989 Liu & Layland 经典论文):固定优先级调度周期任务的可调度性分析方法。

• Rate Monotonic:周期短的任务优先级高(周期单调)。
• 可调度性:给定任务集,是否都能在 deadline 内完成?

4.2 RMA 的模型

RMA 的任务模型:

• 任务集 τ = {τ_1, τ_2, …, τ_n},每任务 τ_i:
  • 周期 T_i(周期性触发)
  • 执行时间 C_i(每周期执行)
  • deadline D_i = T_i(隐含 deadline,周期末)
• 优先级:周期短 = 优先级高(T_i 小 = 优先级高)。
• 假设:任务独立(无共享资源)/周期/执行时间固定/无阻塞/抢占式。

4.3 利用率上界 69%

Liu & Layland 证明:固定优先级(RMA)的可调度利用率上界:

$$U=\sum _{i=1}^n\frac{C_i}{T_i}\le n(2^{1/n}-1)$$

• n=1:100%
• n=2:82.8%
• n=3:78.0%
• n→∞:ln2 ≈ 69.3%

结论:若总利用率 U ≤ 69.3%,任务集一定可调度(充分条件)。 超过 69.3% 不一定不可调度(要看具体任务),但保证可调度的充分上界是 69.3%。

4.4 RMA 的工程意义

RMA 的工程意义:

• 可静态分析:编译期/设计期算 U,判断可调度性,不需运行时测试。
• 保守上界:69.3% 是充分条件(保证可调度),实际可调度任务集可能 U 更高(但无保证)。
• 认证友好:可静态分析 = 认证可追溯(⑧篇 μC/OS 全静态 + RMA)。

4.5 RMA 的修正:阻塞时间

RMA 假设"无阻塞",实际有共享资源(临界区/互斥量)。修正:

$$R_i=C_i+B_i+\sum _{j\in hp(i)}\lceil \frac{R_i}{T_j}\rceil C_j$$

• R_i:任务 i 的最坏响应时间
• C_i:执行时间
• B_i:阻塞时间(被低优先级任务持有资源阻塞,如优先级继承下的临界区)
• hp(i):比 i 高优先级的任务集
• 求和:高优先级任务的干扰

响应时间分析(RTA):迭代求 R_i,直到 R_i ≤ D_i(可调度)或 R_i > D_i(不可调度)。

4.6 RMA 工程实例

AEGIX 安全核实例:

任务集(周期任务):
  τ1: 姿态控制,  T1=1ms,  C1=200μs  (优先级最高)
  τ2: 位置控制,  T2=5ms,  C2=500μs
  τ3: 导航计算,  T3=10ms, C3=1ms
  τ4: 健康监测,  T4=100ms,C4=2ms

利用率:
  U = 200/1000 + 500/5000 + 1000/10000 + 2000/100000
    = 0.2 + 0.1 + 0.1 + 0.02 = 0.42 (42%)

42% < 69.3%,RMA 充分条件满足,可调度。

加阻塞时间(RTA):
  R1 = C1 + B1(τ1 被低优先级阻塞,如共享传感器互斥量)
     = 200μs + 50μs(最长临界区) = 250μs < 1000μs ✓
  R2 = C2 + B2 + ceil(R2/T1)*C1
     迭代求 R2...

这是 安全核可调度性分析的范例——设计期算 U + RTA,证明 deadline 可达,认证有据。这是⑮篇对安全设计的直接价值。

---

五、EDF:理论最优 100% 与工程劣势

5.1 EDF 的设计

EDF(Earliest Deadline First,最早截止期优先):动态优先级调度,任务优先级 = deadline 远近,deadline 近的先跑。

任务 A: deadline 10ms
任务 B: deadline 5ms
任务 C: deadline 8ms

调度顺序(按 deadline 近):B(5) → C(8) → A(10)

5.2 EDF 的理论最优

Liu & Layland 证明:EDF 的可调度利用率上界 100%(单处理器):

$$U=\sum \frac{C_i}{T_i}\le 1$$

• 理论最优:单处理器上,EDF 是最优调度(任何可调度的任务集 EDF 都能调度)。
• 对照 RMA:RMA 69.3%,EDF 100%——EDF 理论上能调度更多任务(利用率更高)。

5.3 EDF 的工程劣势

EDF 的工程劣势(关键):

• 过载雪崩:U > 100% 时,所有任务都错过 deadline(无降级,全崩)。固定优先级过载时低优先级饿死(可预测降级,关键保)。
• 动态优先级难静态分析:deadline 变,优先级变,可调度性分析复杂(需详细任务模型 + 运行时跟踪)。
• 实现复杂:动态优先级要维护 deadline 排序(堆/红黑树),调度开销比固定优先级位图(O(1))大(O(log n))。
• 过载检测难:何时"过载"?难静态判断,运行时才发现(全崩)。

5.4 EDF 过载雪崩的机制

EDF 过载雪崩:

正常(U ≤ 100%):
  每 deadline 都满足,系统稳定

过载(U > 100%):
  某任务错过 deadline → 下周期更紧 → 更多错过
  → 雪崩:所有任务都错过,系统失控
  → 无降级(EDF 不区分关键/非关键)

对照固定优先级过载:

固定优先级过载(U > 上界):
  高优先级任务保 deadline(优先级高,先跑)
  低优先级任务饿死(不执行)
  → 可预测降级:关键保,非关键饿死

5.5 EDF 仅特殊场景用

EDF 仅特殊场景用:

• 利用率紧 + 任务模型清晰:U 在 69.3%-100% 之间,固定优先级不够,EDF 榨取利用率。
• 过载保护配套:配 watchdog/优先级天花板,防雪崩。
• 代表:VxWorks(EDF 可选,⑩篇)/NuttX(EDF 可选)/QNX(SCHED_SPORADIC 类 EDF 思想,⑫篇)。

5.6 论点:EDF 最优 ≠ 该用 EDF

论点:EDF 理论最优(100%)但工程不主流,因"过载雪崩 + 难静态分析 + 实现复杂"——工程选固定优先级(RMA 69%)换"可静态分析 + 过载可降级 + O(1) 实现"。 这是"理论最优 ≠ 工程最优"的范例——工程选"可预测降级"而非"理论最高利用率",因安全关键场景"过载可降级"比"榨取利用率"重要。

---

六、固定 vs 动态优先级:为何主流用固定

6.1 全景对照

维度	固定优先级(RMA)	动态优先级(EDF)
利用率上界	69.3%(n→∞)	100%
过载行为	低优先级饿死(可降级)	全崩(雪崩)
静态分析	✓(RMA/RTA)	难(动态)
实现	O(1) 位图	O(log n) 堆/树
优先级规划	静态(设计期)	动态(运行时)
认证	友好(可追溯)	难(动态难追溯)
工程主流	✓(FreeRTOS/μC/OS/ThreadX/VxWorks 默认)	特殊(VxWorks/NuttX 可选)

6.2 为何主流用固定

固定优先级主流的四个根:

1. 可静态分析(RMA):设计期算可调度性,认证可追溯(⑧篇 μC/OS 全静态 + RMA)。
2. 过载可预测降级:关键任务保 deadline,非关键饿死——可接受的降级(系统设计时设关键高优先级)。
3. O(1) 实现:位图 + CLZ,调度开销恒定,硬实时(T_sched 恒定)。
4. 优先级规划直观:工程师设计期设优先级,可理解可调优。

这四点让固定优先级成为 RTOS 主流——EDF 理论最优但缺这四点(动态难分析/雪崩/O(log n)/不直观),仅特殊场景用。

6.3 Linux CFS:GPOS 的动态优先级

对照 Linux CFS(Completely Fair Scheduler):

• 动态优先级:vruntime(虚拟运行时间)小的先跑,红黑树 O(log n)。
• 目标:公平(所有任务平等分 CPU),非最坏情况。
• 不用 RMA/EDF:GPOS 不需可静态分析(优化公平非 deadline),用 CFS 公平调度。

GPOS 用动态(CFS 公平),RTOS 用固定(RMA 可分析)——目标函数不同(GPOS 公平/吞吐,RTOS 最坏情况),调度策略不同。这是①篇目标函数分野在调度层的实证。

6.4 工程选型实践

安全核调度选型:

• 默认固定优先级抢占(RMA):可静态分析 + 过载可降级 + O(1)。
• 同优先级 RR(非关键任务):公平,不饿死。
• 关键任务独占优先级(不 RR):姿态控制等硬实时,独占优先级,保证 deadline。
• EDF 不用:过载雪崩风险,认证难,不值。
• 优先级规划:设计期静态分配,认证追溯。

这是安全核调度的工程主流选型——固定优先级 + RMA 分析 + 关键任务独占。

---

七、临界区:实时性命门

7.1 临界区的定义

临界区(critical section):访问共享资源的代码段,需互斥保护(关中断/关调度/互斥量)。

/* FreeRTOS 临界区(关中断) */
taskENTER_CRITICAL();
shared_counter++;  /* 临界区 */
taskEXIT_CRITICAL();

/* 关调度(不关中断) */
vTaskSuspendAll();
shared_data = compute();  /* 临界区 */
xTaskResumeAll();

7.2 临界区是实时性命门

论点:RTOS 实时性上限 ≈ 最长关中断时间 + 最长关调度临界区。

• 关中断临界区:关中断期间,所有中断(包括高优先级 ISR)被阻塞,ISR 延迟 = 最长关中断时间。
• 关调度临界区:关调度期间,任务切换被阻塞,高优先级任务延迟 = 最长关调度临界区。

/* 危险:长关中断 */
taskENTER_CRITICAL();
for (int i = 0; i < 1000; i++) {
    big_array[i] = compute(i);  /* 长临界区,关中断几百微秒 */
}
taskEXIT_CRITICAL();
/* → ISR 延迟几百微秒,实时性崩 */

7.3 量最长关中断时间

调试实时问题的第一动作:量最长关中断时间。

• 逻辑分析仪:测 ISR 响应(外部中断到 ISR 第一条指令),多次量取 max。
• RTOS 统计 API:FreeRTOS 无直接,但可用 taskENTER_CRITICAL 前后读硬件计数器(Cortex-M DWT_CYCCNT)。
• 工具:Tracealyzer/Percepio 等可视化工具,trace 关中断区间。

经验阈值:硬实时系统最长关中断应 < 10-50μs(视 deadline),超则查哪处长临界区。

7.4 FreeRTOS 的分层中断

FreeRTOS 用 configMAX_SYSCALL_INTERRUPT_PRIORITY 分层:

• 高优先级中断(> MAX_SYSCALL):不可调用 RTOS API,但不被 RTOS 关中断影响(实时关键 ISR,如电机 PWM)。
• 低优先级中断(≤ MAX_SYSCALL):可调用 FromISR API,但被 taskENTER_CRITICAL 关闭。

/* FreeRTOSConfig.h */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 5  /* 优先级 5-15 可调用 API,0-4 不可 */

/* 高优先级 ISR(0-4):不被 RTOS 关中断影响,实时关键 */
void MotorPWM_ISR(void) {  /* 优先级 2,不可调 RTOS API */
    /* 直接处理,不等 RTOS */
}

/* 低优先级 ISR(5-15):可调 FromISR,但被 taskENTER_CRITICAL 关 */
void UART_ISR(void) {  /* 优先级 6 */
    xQueueSendFromISR(...);  /* 可调 API */
}

分层中断的意义:实时关键 ISR(电机/传感器采集)放高优先级,不被 RTOS 临界区影响;非关键 ISR(UART/网络)放低优先级,可调 RTOS API。这是 FreeRTOS "临界区不拖累实时关键 ISR"的设计。

7.5 临界区工程实践

安全核临界区工程实践:

1. 临界区极短:几条指令,不调耗时函数(不打印/不计算/不 IO)。
2. 关中断 vs 关调度:关中断(保护 ISR 也访问的数据)/ 关调度(只保护任务访问的数据,中断可响)——能用关调度不用关中断(更细粒度,RT-Thread 调度器锁,⑦篇)。
3. mutex 替代长临界区:长临界区用 mutex(优先级继承),不关中断/关调度(影响小)。
4. deferred 模式:ISR 最小工作 + 任务处理(⑭篇),减少 ISR 内临界区。
5. 量最长关中断:调试第一动作,超阈值查长临界区。

---

八、worst-case latency 五分量再分解

8.1 五分量回顾

⑤篇立了 worst-case latency 五分量:

$$T_{max}=T_{sched}+T_{preempt}+T_{critical}+T_{dispatch}+T_{execute}$$

本篇逐项展开压缩手段:

分量	含义	RTOS 压缩手段
T_sched	调度器决策时间	O(1) 位图 + CLZ(恒定)
T_preempt	抢占响应(中断到切换)	硬件中断延迟(PendSV/最低优先级)
T_critical	临界区阻塞	短临界区 + 分层中断 + mutex
T_dispatch	上下文切换	PendSV 保存/恢复寄存器(纳秒)
T_execute	任务执行到完成	任务设计(C_i 控制)

8.2 T_sched:O(1) 调度

• O(1) 位图 + CLZ:1 周期找最高优先级,T_sched 恒定(不随任务数)。
• 对照 CFS O(log n):Linux CFS 红黑树,T_sched 随任务数增长——GPOS 不需恒定。

8.3 T_preempt:中断延迟

• 硬件中断延迟:中断到 ISR 第一条指令,Cortex-M 几个周期(12 cycles)。
• PendSV 切换:ISR 返回后 PendSV 做切换,PendSV 最低优先级(等所有 ISR 退出)。
• T_preempt ≈ 中断延迟 + PendSV 延迟:亚微秒。

8.4 T_critical:临界区(命门)

• 最长关中断:T_critical 的主分量(⑦节)。
• 最长关调度:次分量。
• 压缩:短临界区 + 分层中断 + mutex 替代长临界区。

8.5 T_dispatch:上下文切换

• PendSV 保存/恢复:r4-r11(硬件保存 r0-r3/r12/lr/pc/xpsr),几十周期。
• 纳秒级:Cortex-M 几十 ns。
• 对照进程切换:进程换页表/刷 TLB,微秒级 + 抖动(②篇)。

8.6 T_execute:任务执行

• C_i:任务执行时间,设计期量算/测量。
• 压缩:算法优化/任务拆分/硬件加速。

8.7 五分量加和 ≤ deadline

$$T_{max}=T_{sched}+T_{preempt}+T_{critical}+T_{dispatch}+T_{execute}\le D_i$$

这是硬实时"数学可证"的根——逐项量算五分量,加和 ≤ deadline,则最坏情况可达。AEGIX 安全核姿态控制(deadline 1ms):

T_sched:     100 ns (O(1) 位图)
T_preempt:   200 ns (中断 + PendSV)
T_critical:  5 μs    (最长关中断,工程控制)
T_dispatch:  100 ns (PendSV 切换)
T_execute:   200 μs (姿态控制算法 C_i)
T_max:       ≈ 205.4 μs << 1000 μs (deadline) ✓

这就是⑮篇对安全核"deadline 可达"的数学证明——五分量加和远小于 deadline,留足余量。这是硬实时工程的核心方法论。

---

九、RTOS 语境微内核重新赢

9.1 宏内核 vs 微内核的调度/抢占维度

④篇讲微内核赢安全关键,本篇从调度/抢占维度再论证:

维度	宏内核	微内核
内核代码量	大(Linux 几百万行)	小(seL4 ~1万行/QNX 几百KB)
临界区数	多(几千锁)	少(内核小)
完全抢占实现	极难(VxWorks 旗舰才做)	相对易(内核小锁少)
驱动位置	内核态(驱动 bug 全崩)	用户态(驱动崩只崩自己)
IPC 开销	函数调用(纳秒)	消息传递(微秒)
平均延迟	低(函数调用快)	略高(IPC 开销)
最坏情况	难 bound(驱动 bug/长临界区)	可 bound(内核小+隔离)

9.2 微内核"恒定开销 + 强隔离"

RTOS 语境(安全关键)微内核重新赢的根:

• 恒定开销:微内核代码小,临界区少,T_critical 恒定可 bound;宏内核驱动多,长临界区难 bound。
• 强隔离:驱动/服务用户态,bug 只崩自己,不拖垮内核;宏内核驱动 bug 全崩。
• 可证:seL4 形式化验证内核正确(④篇),宏内核无法形式化(代码量大)。

9.3 “平均快 + 全崩风险” vs “恒定开销 + 强隔离”

• 宏内核:平均快(函数调用纳秒),但驱动 bug 全崩,最坏情况难 bound(某驱动关中断长/死锁,全系统卡)。
• 微内核:恒定开销(IPC 微秒,比函数调用慢),但强隔离(服务崩只崩自己),最坏情况可 bound。

论点:RTOS 语境(安全关键)选"恒定开销 + 强隔离"(微内核)而非"平均快 + 全崩风险"(宏内核)——因安全关键要"最坏情况可 bound",微内核的隔离+小内核让 worst-case 可分析,宏内核的驱动域致命风险不可接受。 这是④篇分赛道结论在调度/抢占维度的再论证。

---

十、"实时≠快"最终澄清

10.1 "实时≠快"的精确表述

①篇立了"实时 ≠ 快",本篇最终澄清:

• 快(fast):平均延迟低(average latency low)。
• 实时(real-time):最坏情况可预测(worst-case bound),即 T_max ≤ deadline。

两者不等价:

系统	平均延迟	最坏情况	是否实时
A	10μs	10ms(偶尔)	否(最坏 10ms 不可 bound)
B	50μs	50μs(恒定)	是(最坏 50μs ≤ deadline)

B 比 A 慢(平均 50μs > 10μs),但 B 实时,A 不实时——B 的最坏情况可预测,A 的最坏情况(10ms)可能超 deadline。

10.2 jitter(抖动)的定义

jitter(抖动):响应时间的 max - min。

• 实时要求 jitter 小:max 接近 min(恒定)。
• 快不要求 jitter:平均低即可,max 可能远大于 min。

系统 A: 10μs(平均), 10ms(max) → jitter ≈ 10ms(大,非实时)
系统 B: 50μs(恒定)            → jitter ≈ 0(小,实时)

10.3 三大实时性误区

⑯篇详三大误区纠正,本篇预热:

1. “快 = 实时”:错。实时是 worst-case bound,非平均快。
2. “低延迟 = 实时”:错。低平均延迟 ≠ 最坏情况可 bound(可能偶尔高)。
3. “PREEMPT_RT = RTOS”:错。PREEMPT_RT 压 Linux 抖动到百微秒,但仍非硬实时(无数学可 bound,GC/驱动长临界区仍在)。

10.4 工程判据

安全核实时性工程判据:

• 量 worst-case(非平均):逻辑分析仪/Tracealyzer 量 max 响应时间。
• 算 RMA/RTA:设计期算可调度性,T_max ≤ deadline。
• 量最长关中断:T_critical 是命门。
• jitter 监控:运行时监控 jitter,max - min 应小。

这是"实时≠快"在工程的落地——不优化平均,优化最坏情况;不凭感觉"感觉快",量 worst-case + 算 RMA。

10.5 论点:实时是数学,不是感觉

论点:实时性是可数学证明的(T_max ≤ deadline),不是凭感觉"感觉快"。 RTOS 工程师的方法论是"量 worst-case + 算 RMA + 控临界区",不是"跑跑看感觉快"。这是①篇"实时 ≠ 快"的工程方法论收束——实时是数学,可证可量,非主观。

---

十一、小结速查

11.1 调度与抢占两轴速查

调度策略:协作/优先级抢占/RR/EDF(选谁)
抢占粒度:协作/抢占点/任意点/完全抢占内核(何时切)
两轴正交:FreeRTOS(优先级+任意点)/VxWorks(优先级+完全抢占)/NuttX(EDF可选+任意点)
实时性 = 调度策略 × 抢占粒度 × 临界区(联合函数)

11.2 抢占四级阶梯速查

①协作式:主动 yield,非实时(任务不让则全等)
②抢占点:内核显式点,中(点间不可抢)
③任意点:用户态任意可抢,内核临界区不可(FreeRTOS/μC/OS/ThreadX 主流)
④完全抢占内核:内核态任意可抢(VxWorks/QNX,工程代价数量级跃升)
Cortex-M:PendSV(最低优先级)做切换,避免栈混乱

11.3 优先级抢占速查

固定优先级:静态,O(1) 位图+CLZ,过载低优先级饿死(可降级)
同优先级 RR:时间片轮转,公平(非关键任务)
O(1) 调度:位图找最高优先级(1 周期 CLZ)+ 链表头,T_sched 恒定
过载可预测降级:关键任务保 deadline,非关键饿死(可接受)
对照 CFS:GPOS 动态(vruntime 公平),RTOS 固定(可分析)

11.4 RMA 速查

RMA(1989 Liu & Layland):固定优先级,周期短=优先级高
利用率上界:U ≤ n(2^(1/n)-1),n→∞ ≈ 69.3%(ln2)
充分条件:U ≤ 69.3% 一定可调度
修正(RTA):加阻塞时间 B_i + 高优先级干扰,R_i = C_i + B_i + Σceil(R_i/T_j)C_j
工程意义:可静态分析/保守上界/认证友好

11.5 EDF 速查

EDF:动态优先级,deadline 近先跑,利用率上界 100%(单处理器最优)
工程劣势:过载雪崩(全错过)/动态难静态分析/O(log n) 实现/过载检测难
论点:EDF 最优 ≠ 该用 EDF(过载雪崩不可接受)
仅特殊场景:利用率紧+任务模型清晰+过载保护配套(VxWorks/NuttX 可选)

11.6 固定 vs 动态速查

固定优先级(RMA):69.3% 上界/过载可降级/可静态分析/O(1)/认证友好 → 主流
动态 EDF:100% 上界/过载雪崩/难静态分析/O(log n)/认证难 → 特殊
工程主流:固定优先级(可分析+可降级+O(1))
GPOS CFS:动态(vruntime 公平),非 RMA/EDF(目标公平非 deadline)

11.7 临界区命门速查

临界区:关中断/关调度/互斥量保护的共享资源代码段
命门:RTOS 实时性上限 ≈ 最长关中断 + 最长关调度
关中断:所有 ISR 阻塞,ISR 延迟 = 最长关中断
关调度:任务不切,高优先级延迟 = 最长关调度
分层中断:configMAX_SYSCALL_INTERRUPT_PRIORITY,高优先级 ISR 不被 RTOS 关
调试第一动作:量最长关中断(逻辑分析仪/DWT_CYCCNT/Tracealyzer)
工程:临界区极短/关调度优于关中断/mutex 替代长临界区/deferred 模式

11.8 worst-case latency 五分量速查

T_max = T_sched + T_preempt + T_critical + T_dispatch + T_execute
T_sched:O(1) 位图(恒定)
T_preempt:中断延迟+PendSV(亚微秒)
T_critical:最长关中断/关调度(命门,工程控)
T_dispatch:上下文切换(纳秒,PendSV 保存恢复)
T_execute:任务执行(C_i,设计控)
硬实时可证:五分量加和 ≤ deadline(AEGIX 205μs << 1ms)

11.9 微内核重新赢速查

宏内核:平均快(函数调用纳秒)+ 驱动 bug 全崩 + 最坏难 bound
微内核:恒定开销(IPC 微秒)+ 强隔离(服务崩只崩自己)+ 最坏可 bound
RTOS 安全关键:选"恒定开销+强隔离"(微)非"平均快+全崩风险"(宏)

11.10 "实时≠快"速查

快:平均延迟低;实时:最坏情况可 bound(T_max ≤ deadline)
jitter:max-min,实时要求 jitter 小
系统 A(平均 10μs,偶尔 10ms):快但非实时
系统 B(恒定 50μs):慢但实时
三大误区:快=实时(错)/低延迟=实时(错)/PREEMPT_RT=RTOS(错)
工程:量 worst-case(非平均)+ 算 RMA + 量最长关中断 + jitter 监控
实时是数学可证,非感觉

11.11 关键论点速查(本篇)

1. 实时性是"调度策略 × 抢占粒度 × 临界区"的联合函数,非"调度算法多高级"。
2. 抢占四级阶梯:协作→抢占点→任意点→完全抢占;③任意点是 MCU RTOS 主流,④完全抢占是硬实时旗舰(工程代价数量级跃升)。
3. 固定优先级 O(1) 调度(位图+CLZ)是 RTOS 硬实时根基,T_sched 恒定。
4. RMA 利用率上界 69.3%(n→∞),可静态分析,认证友好;加阻塞修正(RTA)。
5. EDF 理论最优 100% 但过载雪崩(全崩),工程不主流——理论最优 ≠ 工程最优。
6. 固定优先级主流因"可静态分析 + 过载可降级 + O(1) + 直观";EDF 仅特殊场景。
7. 临界区是实时性命门:RTOS 实时性上限 ≈ 最长关中断 + 最长关调度。
8. 调试实时问题第一动作:量最长关中断时间(八成在临界区与优先级反转,不在硬件)。
9. worst-case latency 五分量加和 ≤ deadline = 硬实时数学可证(AEGIX 205μs << 1ms)。
10. RTOS 语境微内核重新赢:恒定开销+强隔离 > 平均快+全崩风险;AEGIX 双核物理隔离替代。
11. “实时 ≠ 快”:实时是 worst-case bound(数学可证),非平均快(感觉)。

---

十二、相关笔记

• [[00-操作系统设计思想系列总目录]] —— 系列入口
• [[14-RTOS原语设计思想-任务-信号量-互斥量-队列-事件组]] —— 上一篇(原语层)
• [[16-Linux-vs-RTOS与选型决策-误区纠正-五维权衡-问题性质回退法]] —— 下一篇(选型收束)
• [[05-RTOS核心矛盾-资源受限×时间确定性决策树]] —— 六轴框架 + worst-case latency 五分量(⑤篇)
• [[01-操作系统的本质-五件事-目标函数-GPOS-vs-RTOS]] —— 实时性形式化定义(①篇)
• [[04-内核架构三态-宏-微-混合内核]] —— 微内核重新赢的理论底座
• [[10-VxWorks深度-硬实时旗舰-完全抢占内核]] —— 完全抢占内核 + EDF 可选
• [[12-QNX深度-微内核+硬实时+车规统一]] —— 微内核完全抢占 + SCHED_SPORADIC
• [[11-ThreadX深度-预抢占阈值-认证型设计]] —— PIC(原语层调度巧思)
• [[06-FreeRTOS深度-极简可移植范本]] —— O(1) 调度器源码 + PendSV

---

[[00-操作系统设计思想系列总目录]] · 上一篇:[[14-RTOS原语设计思想-任务-信号量-互斥量-队列-事件组]] · 下一篇:[[16-Linux-vs-RTOS与选型决策-误区纠正-五维权衡-问题性质回退法]] · L4 收官(调度与抢占机制)

---

✨ 感谢你的阅读 ✨

技术之路漫漫，分享是为了更好地交流。
如果本文的内容对你有启发，希望能得到你的支持：

👍 点赞   |   ⭐ 收藏   |   👀 关注

如果你在调试过程中遇到了其他问题，
欢迎在 评论区 💬 留言，我们一起探讨。

关注我，一起交流底层开发的那些事儿！🚀

---