第1章：任务与任务控制块——任务的状态机模型与TCB数据结构解析

各位同学，咱们今天聊点实在的。任务状态机，说白了就是RTOS里任务的“生老病死”。你想想看，一个任务从创建到销毁，中间会经历哪些状态？就绪、运行、阻塞、挂起——这四个状态，我做了十年嵌入式，几乎每天都在跟它们打交道。

1.1 任务状态机：四个核心状态

先看一张最基础的图（嗯，我这里用文字描述，你脑补一下）：

创建 → 就绪 → 运行 → 阻塞/挂起 → 就绪 → ... → 销毁

每个任务在任意时刻，只能处于其中一个状态。我刚开始学RTOS时，总以为任务状态很简单，直到有一次在项目中调试一个死锁问题，才发现状态切换的细节有多坑。

就绪态（Ready）

任务已经准备好运行，只等CPU分配时间片。说白了，就是“万事俱备，只欠东风”。

• 任务在就绪队列中排队
• 优先级决定谁先被调度
• 我习惯把就绪队列想象成“候诊室”——任务都在等着叫号

运行态（Running）

任务正在占用CPU执行代码。注意，单核CPU上同一时刻只能有一个任务在运行。

• 任务从就绪态被调度器选中后进入运行态
• 运行态的任务可能被更高优先级任务抢占
• 我曾经遇到过一个bug：一个任务在运行态里死循环，导致其他任务永远得不到CPU——这就是典型的“优先级反转”前兆

阻塞态（Blocked）

任务因为等待某个事件（比如信号量、消息队列、延时）而暂停执行。这是RTOS里最常用的状态。

• 阻塞态的任务不占用CPU
• 事件发生后，任务自动回到就绪态
• 避坑指南：我曾经在项目里把阻塞超时设成了0，结果任务永远阻塞——后来查了三天才发现

挂起态（Suspended）

任务被主动暂停，通常由其他任务或中断调用挂起函数触发。挂起态的任务不会自动恢复，必须由其他任务显式唤醒。

• 挂起态和阻塞态的区别：阻塞是“被动等待”，挂起是“主动暂停”
• 我建议：挂起态尽量少用，除非你有明确的场景（比如调试、低功耗模式）

1.2 TCB数据结构：任务的“身份证”

每个任务在RTOS内核里都有一个对应的控制块——TCB（Task Control Block）。你可以把它想象成任务的“身份证”，里面记录了任务的所有关键信息。

我见过很多新手直接忽略TCB，结果出了问题根本不知道从哪里查起。其实，理解了TCB，你就理解了RTOS的调度机制。

TCB的核心字段

字段名	类型	说明
task_id	uint32_t	任务唯一标识符
state	enum	当前状态（就绪/运行/阻塞/挂起）
priority	uint8_t	任务优先级（数值越小优先级越高）
stack_ptr	void*	栈指针，保存任务上下文
stack_size	uint32_t	栈大小（字节）
delay_ticks	uint32_t	阻塞延时剩余时间
event_list	list_head	等待的事件链表

嗯，这里要注意：不同RTOS的TCB实现会有差异，但核心字段大同小异。我习惯在调试时直接打印TCB内容，比看日志快多了。

TCB在内存中的布局

TCB通常放在静态内存区（全局变量）或动态堆中。我个人更推荐静态分配——原因很简单：动态分配容易产生碎片，而且调试起来麻烦。

// 一个简化的TCB结构体示例
typedef struct {
    uint32_t    task_id;        // 任务ID
    uint8_t     state;          // 任务状态
    uint8_t     priority;       // 优先级
    void*       stack_ptr;      // 栈指针
    uint32_t    stack_size;     // 栈大小
    uint32_t    delay_ticks;    // 延时计数
    void*       event_wait;     // 等待的事件对象
} TCB_t;

你看，这个结构体只有几十个字节，但内核就是靠它来管理所有任务的。我记得有一次，一个同事把stack_size写成了0，结果任务一运行就栈溢出——查了两天才发现是TCB初始化时忘了赋值。

1.3 状态切换的底层机制

任务状态切换，本质上就是修改TCB里的state字段，然后把TCB从一个链表移到另一个链表。听起来简单，但实现起来有很多细节。

就绪→运行：调度器的工作

调度器从就绪队列中取出最高优先级的任务，把它的TCB标记为运行态，然后恢复该任务的上下文（寄存器、栈等）。

运行→阻塞：主动让出CPU

任务调用延时函数或等待事件时，内核会：

1. 保存当前任务的上下文到TCB
2. 把TCB从就绪队列移到阻塞队列
3. 触发一次调度，让其他任务运行

阻塞→就绪：事件唤醒

当事件发生时（比如延时到期、信号量释放），内核会把对应的TCB从阻塞队列移到就绪队列。注意，这里有个优先级问题——高优先级任务会被优先唤醒。

1.4 避坑指南：状态机相关的常见问题

做RTOS开发，状态机相关的坑我踩过不少。下面列几个最常见的：

• 任务永远阻塞：等待的事件永远不会发生。我曾经在项目里用了一个全局变量做事件标志，结果忘了在中断里置位——任务就永远卡在阻塞态了。
• 挂起态误用：挂起一个任务后忘了唤醒，导致系统功能异常。我建议：挂起操作一定要成对出现，挂起和唤醒之间做好日志记录。
• 优先级反转：低优先级任务占用资源，导致高优先级任务被阻塞。这个后面章节会详细讲，但这里先提一句——使用优先级继承协议可以解决。
• 栈溢出：TCB里的stack_size设置过小，任务运行时栈溢出覆盖了其他数据。我习惯在TCB里加一个栈边界标记，定期检查是否被破坏。

1.5 小结

这一章我们聊了任务状态机的四个核心状态，以及TCB数据结构的关键字段。说白了，RTOS的调度就是围绕TCB和状态切换展开的。你想想看，一个只有几十字节的结构体，却能管理成百上千个任务——这就是嵌入式系统的魅力。

下一章，我们会深入讨论优先级调度算法。到时候我会分享一个我在工业控制项目里遇到的优先级反转案例，保证让你印象深刻。

好，今天就到这里。有问题随时交流。