2. 任务与任务控制块：任务的状态机模型与TCB数据结构设计

大家好，我是老吴。今天咱们聊聊RTOS里最核心的两个概念——任务状态机和任务控制块。说实话，我做了十几年嵌入式开发，见过太多工程师在这上面栽跟头。你想想看，任务调度说白了就是操作系统在管理一堆“并发执行”的函数，那它怎么知道每个任务当前在干嘛？又怎么在任务间切换？答案就在状态机和TCB里。

2.1 任务的状态机模型

一个任务从创建到销毁，它的“生命状态”是不断变化的。我习惯把任务想象成一个工人：他可能在干活（运行），可能在等材料（阻塞），也可能被老板叫去喝茶（挂起）。RTOS里，任务通常有四种基本状态：

  • 就绪（Ready）：任务已经准备好，随时可以运行。它只等CPU分配时间片。
  • 运行（Running）：任务正在占用CPU执行代码。同一时刻，单核MCU上只有一个任务处于此状态。
  • 阻塞（Blocked）：任务在等待某个事件，比如等待信号量、等待队列消息、等待延时结束。它暂时不参与CPU竞争。
  • 挂起（Suspended）：任务被主动暂停，通常由其他任务或中断调用挂起函数。它不参与调度，直到被恢复。

重要： 有些RTOS（比如FreeRTOS）把“挂起”和“阻塞”合并为一个状态叫“非运行态”，但底层逻辑是一样的。我个人习惯把挂起单独拎出来，因为它在调试时特别有用——你可以挂起一个任务，观察系统行为，而不影响其他任务。

状态之间的转换，我画个简图你就能明白：

创建 → 就绪 → 运行 → 阻塞 → 就绪
                ↓        ↑
              挂起 ←—— 恢复

嗯，这里要注意：从“运行”到“就绪”通常是因为时间片用完或被更高优先级任务抢占。从“运行”到“阻塞”是因为任务主动等待资源。从“运行”到“挂起”则是被外部强制暂停。

我的经验： 我在一个电机控制项目里遇到过一个问题——任务莫名其妙不跑了。后来发现是某个中断服务函数里调用了挂起函数，把控制任务给挂起了。从那以后，我定了个规矩：中断里只发信号，不做任务状态切换。你想想看，中断上下文里改任务状态，调度器都不知道该听谁的。

2.2 任务控制块（TCB）的数据结构设计

任务控制块，说白了就是任务的“身份证”和“档案袋”。每个任务在创建时，内核都会给它分配一个TCB。TCB里存了所有调度需要的信息。我设计TCB时，会考虑以下几个核心字段：

字段名 类型 说明
task_id uint16_t 任务唯一标识符，用于调试和查找
state enum 当前状态：就绪、运行、阻塞、挂起
priority uint8_t 任务优先级，数值越小优先级越高
stack_ptr void* 当前栈指针，保存任务上下文
stack_base void* 栈底地址，用于栈溢出检测
stack_size uint32_t 栈大小，单位字节
delay_ticks uint32_t 阻塞延时剩余时间，用于vTaskDelay
event_list list_t 等待的事件链表，用于信号量、队列等
next TCB* 链表指针，用于就绪队列或阻塞队列

你看，这个结构体其实不大，但每个字段都不可或缺。我见过有人把TCB设计成上百字节的庞然大物，结果在资源紧张的MCU上跑不起来。记住：嵌入式系统里，每字节都珍贵。

避坑指南： 我曾经在一个项目里把stack_ptr和stack_base搞反了。结果任务切换时栈指针指向了错误位置，系统直接跑飞。调试了整整两天才发现——嗯，从那以后我每次写TCB初始化代码，都会用断言检查栈指针是否在合法范围内。

2.3 状态机与TCB的联动

状态机和TCB不是孤立的。调度器通过TCB里的state字段知道任务当前状态，然后决定是否把它加入就绪队列。举个例子：

// 任务A调用vTaskDelay(100)
void vTaskDelay(uint32_t ticks) {
    // 1. 从当前任务TCB获取指针
    TCB_t *current = get_current_task();
    
    // 2. 设置延时时间
    current->delay_ticks = ticks;
    
    // 3. 改变状态为阻塞
    current->state = BLOCKED;
    
    // 4. 从就绪队列移除，加入阻塞队列
    remove_from_ready_list(current);
    add_to_blocked_list(current);
    
    // 5. 触发任务切换
    yield();
}

这段代码虽然简单，但包含了状态机转换的核心逻辑。你想想看，如果没有TCB，调度器怎么知道该把哪个任务从就绪队列移到阻塞队列？所以TCB就是任务在操作系统里的“代言人”。

2.4 设计TCB时的一些个人习惯

做了这么多年，我总结了几条TCB设计原则：

  • 保持精简：TCB里只放调度必须的信息。调试信息（比如任务名、创建时间）可以单独放调试结构体，条件编译控制。
  • 注意对齐：MCU通常要求4字节对齐。我会在TCB开头放一个uint32_t的魔数，用于检测TCB是否被破坏。
  • 预留扩展位：在TCB末尾留几个字节的保留字段，方便后续增加功能（比如CPU使用率统计）。
  • 链表友好：TCB里至少有一个next指针，方便插入各种队列。我习惯用双向链表，虽然多占一个指针，但删除操作更快。

一个小技巧： 我经常在TCB里加一个uint8_t的“错误码”字段。当任务因为某种原因被阻塞或挂起时，记录原因码。调试时只要看这个字段，就知道任务为什么卡住了——比翻日志快多了。

2.5 实际项目中的状态机调试

最后聊点实战经验。调试任务状态机时，我常用两种方法：

  1. 状态打印：在调度器切换任务时，把旧任务和新任务的状态、优先级、ID打印到串口。配合一个简单的Python脚本，就能画出任务状态变化图。
  2. 状态机断言：在状态转换函数里加断言，比如“从运行态只能转到就绪、阻塞或挂起”。一旦出现非法转换，立刻触发硬件错误中断。

我记得有一次，客户反映系统偶尔死机。我用状态打印发现，一个低优先级任务在中断里被直接切换到了运行态——这违反了调度规则。后来查代码，是某个新手工程师在中断里调用了taskYIELD()。嗯，从那以后，我强制要求所有中断服务函数里不能直接调用调度相关API。

好了，关于任务状态机和TCB，今天就聊这么多。下一章咱们会深入讲就绪队列的实现，以及如何用位图法快速找到最高优先级任务。到时候见。

← 上一章 📖 返回目录 下一章 →