📚 课程目录第2章任务模型与调度基础

任务模型与调度基础：任务状态机、TCB 与上下文切换开销

调度器是实时系统的核心。但调度器调度的到底是什么？说白了，就是一个个任务。而任务在系统中的生命历程，就是状态机；任务的身份证，就是 TCB；调度器切换任务时付出的代价，就是上下文切换开销。这三个概念，是理解一切调度行为的基础。

我刚开始做 RTOS 移植时，总觉得状态机是理论课才讲的东西。直到有一次，一个任务莫名其妙“消失”了——既不运行，也不报错。查了两天，才发现是某个驱动把任务挂起了，但没恢复。嗯，从那以后，我每次写任务代码，都会先画一遍状态迁移图。

任务状态机：任务的四种基本状态

一个任务在系统中，不可能永远在跑。它要等资源、等时间、等中断。所以 RTOS 把任务的生命周期抽象成几个状态。最常见的模型是四状态模型：就绪、运行、阻塞、挂起。

核心原则：任何时刻，一个任务只能处于一个状态。调度器只从就绪队列中选任务来运行。

我习惯用一张图来理解状态迁移。下面这张 SVG 图，画的就是任务在四个状态之间的流转路径。

这张图里，箭头代表状态迁移的触发条件。你想想看，一个任务从创建出来，默认是就绪态。调度器选中它，它就进入运行态。如果它主动调用 delay 或等待信号量，就进入阻塞态。等条件满足，再回到就绪态。挂起态比较特殊——它是被人为“冻住”的，调度器根本看不见它。

我的习惯：调试任务异常时，先看它当前在哪个状态。如果任务在就绪队列里但不运行，查优先级；如果在阻塞队列里，查它在等什么资源；如果消失了，查是不是被挂起了。状态就是线索。

任务控制块（TCB）：任务的身份证

每个任务在 RTOS 内核里，都有一个对应的数据结构。这个结构就是 TCB。它记录了任务的所有信息：栈指针、优先级、状态、名字、延时值……调度器操作任务，本质上就是操作 TCB。

我见过不少初学者，把 TCB 当成“理论概念”跳过。直到他们自己写调度器时，才发现 TCB 的设计直接决定了系统的性能和灵活性。说白了，TCB 就是任务的“内核对象”。

下面是一个典型的 TCB 结构体定义。以 FreeRTOS 为例，但几乎所有 RTOS 都大同小异。

typedef struct tskTaskControlBlock {
    volatile StackType_t    *pxTopOfStack;      // 栈顶指针（核心！）
    ListItem_t              xStateListItem;     // 状态链表节点（就绪/阻塞/挂起）
    ListItem_t              xEventListItem;     // 事件链表节点（等待事件）
    UBaseType_t             uxPriority;         // 任务优先级
    StackType_t             *pxStack;           // 栈起始地址
    char                    pcTaskName[configMAX_TASK_NAME_LEN]; // 任务名
    // ... 其他字段（延时、通知值、CPU亲和性等）
} TCB_t;

这里最关键的是 pxTopOfStack。它指向当前任务的栈帧位置。上下文切换时，CPU 的寄存器就是从这里压入和弹出的。我调试过一个 bug，任务切换后 PC 指针飞了，最后发现是栈溢出把 TCB 里的栈顶指针覆盖了。嗯，从那以后，我每个任务栈都多留 20% 的余量。

TCB 中的 xStateListItem 和 xEventListItem 是两个链表节点。前者把任务挂到就绪链表或阻塞链表上；后者用于等待特定事件（比如信号量）。调度器遍历就绪链表时，就是通过 xStateListItem 找到最高优先级任务的。

TCB 字段	作用	我踩过的坑
`pxTopOfStack`	保存/恢复寄存器现场	栈溢出会覆盖它，导致切换崩溃
`xStateListItem`	将任务挂入就绪/阻塞链表	链表操作未关中断，导致链表损坏
`uxPriority`	调度决策依据	动态修改优先级时未重新调度
`pxStack`	栈内存管理	栈地址未对齐，导致硬件异常

警告：TCB 是内核最核心的数据结构。任何对 TCB 的修改（尤其是链表操作），都必须保证原子性。我曾经在中断服务函数里直接修改了任务的优先级，但没有调用调度器——结果任务切换时优先级不一致，系统直接跑飞。记住：操作 TCB 前，先关中断；操作完，再开中断并触发调度。

上下文切换开销：调度器付出的代价

上下文切换，就是暂停当前任务，恢复另一个任务的过程。这个过程不是免费的。每次切换，CPU 都要压栈、弹栈、更新 TCB、切换栈指针。这些操作消耗的 CPU 时间，就是上下文切换开销。

你想想看，如果一个系统里任务切换太频繁，CPU 大部分时间都在“换人”，而不是“干活”。这就是所谓的调度抖动。我优化过一个数据采集系统，原始设计每 1ms 切换一次任务，结果 CPU 负载 70% 都花在切换上。后来把任务合并，切换周期拉到 5ms，吞吐量反而提升了 30%。

上下文切换开销通常包括以下几个部分：

保存当前任务上下文：将 CPU 寄存器（PC、SP、LR、R0-R12 等）压入当前任务栈。
更新当前任务 TCB：将栈顶指针保存到 pxTopOfStack，状态改为就绪。
选择下一个任务：调度器遍历就绪链表，找到最高优先级任务。
恢复新任务上下文：从新任务的 TCB 中取出栈顶指针，弹出寄存器。
跳转到新任务：执行 BX LR 或 POP {PC}，开始运行新任务。

下面这张图，展示了从任务 A 切换到任务 B 时，CPU 和内存的变化过程。

从这张图可以清楚看到，切换开销主要来自寄存器存取和调度器查找。寄存器存取是硬件决定的，基本固定；调度器查找则取决于就绪任务的数量。所以，任务数越多，切换开销越大。

我的优化建议：如果系统对实时性要求极高（比如 10kHz 控制环路），可以考虑用“零延迟调度”技术——在中断退出时直接切换任务，跳过调度器查找。但代价是代码复杂度上升。我个人只在万不得已时才用这招。

避坑指南：我踩过的三个坑

坑一：栈溢出导致 TCB 损坏。 我曾经在任务里定义了一个超大局部数组，结果栈指针直接写到了相邻任务的 TCB 区域。现象是另一个任务随机崩溃。排查方法：在每个任务栈尾部填充固定模式（如 0xDEAD），定期检查是否被覆盖。
坑二：中断中修改 TCB 未保护。 有一次我在 ISR 里释放了信号量，但没关中断。结果刚好被另一个中断打断，两个中断同时操作就绪链表，链表指针直接断裂。从那以后，我所有 TCB 操作都包在 taskENTER_CRITICAL() 里。
坑三：切换频率过高导致系统“假死”。 一个同事把任务延时设为 0，结果两个同优先级任务互相让渡 CPU，切换频率飙到 100kHz。系统看起来在跑，但应用逻辑几乎没进展。解决办法：给每个任务至少加 1 个 tick 的延时，或者用时间片轮转。

好了，任务模型和调度基础就讲到这里。记住三句话：状态机告诉你任务在哪，TCB 告诉你任务是谁，上下文切换开销告诉你调度贵不贵。这三样东西，是后续所有调度分析和调优的基石。