第二章 任务管理核心：任务控制块（TCB）数据结构深度解析、任务状态机
各位同学，咱们今天聊点硬核的。任务控制块，简称TCB，是RTOS里最核心的数据结构。没有它，任务就像没有身份证的人，系统根本没法管理。我做了这么多年嵌入式，见过太多因为TCB设计不合理导致的系统崩溃。说白了，TCB就是任务的“户口本”，系统调度全靠它。
2.1 TCB里到底装了啥？
每个任务在创建时，内核都会给它分配一个TCB。这个结构体里记录着任务的所有“身家性命”。我习惯把TCB里的成员分成几大类：
- 任务栈指针：指向任务自己的栈空间。每个任务都得有独立的栈，不然函数调用一嵌套，数据就乱套了。
- 任务状态：就绪、运行、阻塞、挂起、休眠，五种状态之一。这个咱们后面细聊。
- 优先级：决定了任务被调度的先后顺序。数值越小优先级越高，这是业界惯例。
- 任务ID：唯一标识，方便调试时定位问题。
- 事件等待列表：任务在等什么信号量、消息队列、事件标志组，都记在这里。
- 延时计数器：休眠或阻塞时，记录还剩多少tick要等。
嗯，这里要注意，不同RTOS的TCB实现细节有差异，但核心成员大同小异。我当年在移植FreeRTOS到某款国产MCU时，就发现它的TCB里多了一个“CPU亲和性”字段，用来绑定任务到指定核心。这种设计在AMP架构下特别有用。
核心观点：TCB是RTOS调度器的“数据库”，所有调度决策都基于TCB里的信息。设计TCB时，要兼顾空间占用和访问效率。
2.2 任务状态机：五种状态的流转
任务不是生下来就一直在跑的。它会在就绪、运行、阻塞、挂起、休眠这五种状态之间切换。你想想看，如果所有任务都在运行，那CPU得累死。状态机就是为了让系统有序地分配CPU时间。
| 状态 | 含义 | 典型触发条件 |
|---|---|---|
| 就绪 | 任务已准备好，等待调度器分配CPU | 创建完成、阻塞解除、延时结束 |
| 运行 | 任务正在占用CPU执行 | 调度器选中该任务 |
| 阻塞 | 任务在等待某个资源或事件 | 等待信号量、消息队列、互斥锁 |
| 挂起 | 任务被暂停，不参与调度 | 调用挂起API、其他任务挂起它 |
| 休眠 | 任务主动延时一段时间 | 调用延时函数 |
为什么会这样设计？说白了，就是为了让CPU不空转。如果一个任务在等外设数据，那就让它去阻塞，把CPU让给其他任务。我曾经在一个车载项目中，因为某个任务在轮询等待CAN报文，导致高优先级任务被饿死。后来改成阻塞等待，问题就解决了。
2.3 状态切换的典型场景
咱们看一个实际例子。假设系统里有三个任务：TaskA（优先级5）、TaskB（优先级3）、TaskC（优先级1）。
- 系统启动后，TaskC优先级最高，先进入运行状态。
- TaskC调用延时函数，进入休眠状态，等待100个tick。
- 调度器从就绪队列中选出TaskB（优先级3），TaskB进入运行状态。
- TaskB等待一个信号量，但信号量还没释放，TaskB进入阻塞状态。
- 调度器选出TaskA（优先级5），TaskA进入运行状态。
- 100个tick后，TaskC休眠结束，进入就绪状态。因为优先级最高，它立即抢占TaskA，重新进入运行状态。
你看，状态切换就是这么回事。每个切换点，调度器都要做一次“上下文切换”，保存当前任务的寄存器，恢复新任务的寄存器。这个开销要尽量小，不然系统性能就上不去。
避坑指南：我曾经在调试一个多任务系统时，发现某个任务莫名其妙不跑了。查了半天，原来是它在阻塞状态下被另一个任务挂起了。挂起和阻塞是两个不同的状态，挂起后即使资源可用，任务也不会恢复。这个坑我踩过，大家要小心。
2.4 TCB在调度器中的角色
调度器是怎么知道哪个任务该运行的？它遍历就绪任务列表，找到优先级最高的那个。这个列表里的每个节点，就是一个TCB指针。所以TCB的设计直接影响调度效率。
我见过两种常见的实现方式：
- 优先级位图法：用一个位图记录哪些优先级有就绪任务，然后通过查表找到最高优先级。这种方式查找时间是常数级的，适合实时性要求高的场景。
- 链表法：每个优先级维护一个就绪任务链表。调度时从最高优先级链表取头节点。实现简单，但查找时间随任务数增加而增加。
我个人习惯用位图法，尤其是在车载领域，实时性要求苛刻。不过位图法占用的RAM稍微多一点，对于资源受限的MCU，需要权衡。
2.5 代码示例：TCB结构体定义
下面是一个简化版的TCB定义，来自某款开源RTOS。我加了一些注释，方便大家理解。
typedef struct tcb {
uint32_t *stack_ptr; // 栈指针，指向当前栈顶
uint32_t priority; // 任务优先级
uint32_t state; // 任务状态：就绪/运行/阻塞/挂起/休眠
uint32_t task_id; // 任务ID，调试用
uint32_t delay_ticks; // 延时剩余tick数
void *wait_obj; // 等待的对象（信号量、队列等）
struct tcb *next; // 链表指针，用于就绪队列
struct tcb *prev; // 双向链表，方便删除
} tcb_t;你看，这个结构体很紧凑。每个字段都是32位，对齐到4字节边界，访问效率高。实际产品中，可能还会加入栈大小、任务名、CPU使用率统计等字段。但核心就是这些。
注意事项：TCB的栈指针字段非常关键。如果栈指针被意外修改，任务就会跑飞。我建议在TCB结构体开头放一个“魔数”字段，用来检测TCB是否被破坏。这在调试阶段特别有用。
2.6 任务状态机的实现要点
实现状态机时，要注意状态切换的原子性。比如任务从就绪切换到运行，需要先把它从就绪队列移除，再设置状态为运行。这两个操作必须在一个临界区内完成，否则可能被中断打断，导致队列数据不一致。
我记得在某个项目中，因为中断服务程序里调用了任务切换函数，导致就绪队列被破坏。后来加了临界区保护，问题才解决。嗯，这里要注意，临界区要尽量短，不然会影响系统实时性。
另外，挂起状态比较特殊。任务被挂起后，它不会出现在任何就绪队列里，调度器完全忽略它。只有其他任务调用恢复API，它才能重新进入就绪状态。这个机制常用于调试或低功耗模式。
2.7 总结一下
TCB和任务状态机，是RTOS调度器的基石。理解了它们，你就掌握了任务管理的核心。说白了，调度器就是在TCB之间来回切换，根据状态机规则决定谁该运行。我建议大家在学完理论后，去读一读FreeRTOS或uC/OS的源码，看看它们是怎么实现TCB和状态机的。读源码是提升最快的方式。
下一章，咱们聊聊任务创建和删除的细节，以及栈空间的管理。到时候我会分享一些实际项目中的栈溢出排查经验，敬请期待。