2. 任务模型与状态：任务的定义、任务状态机与TCB结构解析

大家好，我是你们的老朋友。今天我们来聊聊实时操作系统里最核心的概念——任务模型与状态。说实话，我见过不少工程师，代码写得飞起，但一问到任务状态机就含糊其辞。结果呢？调试的时候抓耳挠腮，死活找不到bug在哪。

嗯，咱们今天就把这块硬骨头啃下来。我会结合我这些年踩过的坑，把任务的定义、状态机、还有那个神秘的TCB，掰开了揉碎了讲清楚。

2.1 任务到底是什么？

先问个问题：任务和函数有什么区别？

很多人觉得，任务不就是个死循环函数嘛。这话对了一半。函数是被动调用的，你调它，它执行，执行完就没了。但任务不一样——任务是一个拥有独立生命周期的执行实体。

我个人习惯把任务想象成一个「独立的小人」：

  • 它有自己的私人物品（栈空间、寄存器值）
  • 它有自己的工作节奏（优先级、时间片）
  • 它有自己的情绪状态（就绪、运行、阻塞、挂起）

说白了，任务就是操作系统眼里最小的调度单位。每个任务都觉得自己独占了CPU，但实际上，操作系统在它们之间快速切换，制造了「同时运行」的假象。

核心定义：任务是竞争CPU资源的基本单位，由代码段、数据段、栈空间和TCB共同描述。

2.2 任务状态机——小人的四种状态

我在项目中遇到过最头疼的问题，就是任务莫名其妙不跑了。查了半天，发现是任务状态卡住了。所以，理解状态机是调试的第一步。

实时系统里，任务通常有四种状态：

状态 含义 通俗理解
就绪（Ready） 任务已准备好，随时可以运行 「我准备好了，随时可以干活」
运行（Running） 任务正在占用CPU执行 「我正在干活，别打扰我」
阻塞（Blocked） 任务等待某个事件或资源 「我在等快递，到了叫我」
挂起（Suspended） 任务被强制暂停，不参与调度 「我被关禁闭了，别找我」

你想想看，这四种状态之间是怎么切换的？我画了一张图，一看就明白：

就绪 Ready 运行 Running 阻塞 Blocked 挂起 Suspended 调度器选中 时间片用完/抢占 等待资源/事件 资源就绪/事件到达 任务挂起调用 任务恢复调用 任务状态机

小技巧：调试时如果发现任务不跑，先查它当前在哪个状态。80%的情况是任务在阻塞状态等资源，而资源被别的任务占着不放——这就是经典的「死锁」前兆。

2.3 状态切换的典型场景

光看状态图还不够，咱们得结合代码来理解。我举个例子：

// 伪代码：一个典型任务的执行流程
void my_task(void *arg) {
    while(1) {
        // 状态：就绪 -> 运行（调度器选中）
        do_some_work();  // 运行中
        
        // 等待消息队列
        msg_t msg;
        // 状态：运行 -> 阻塞（等待消息）
        os_msg_recv(&queue, &msg, OS_WAIT_FOREVER);
        // 状态：阻塞 -> 就绪（消息到达，等待调度）
        
        process_msg(&msg);  // 再次进入运行状态
    }
}

我曾经遇到过一个坑：有个任务调用了os_msg_recv，但发送方任务优先级太低，一直没机会发消息。结果接收任务就永远阻塞在那了。后来我加了个超时机制，问题才解决。

注意：永远不要在阻塞状态下等待一个「不可能发生」的事件。否则你的任务就变成「僵尸任务」了——它活着，但永远不干活。

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

操作系统怎么管理这么多任务？靠的就是TCB。你可以把TCB想象成任务的「档案袋」，里面记录了任务的所有关键信息。

我习惯把TCB结构体设计成这样：

typedef struct {
    uint32_t    *stack_ptr;      // 栈指针（保存CPU寄存器）
    uint32_t    stack_size;      // 栈大小
    uint8_t     priority;        // 任务优先级
    uint8_t     state;           // 当前状态（就绪/运行/阻塞/挂起）
    char        name[16];        // 任务名称（方便调试）
    void        (*entry)(void*); // 任务入口函数
    void        *arg;            // 入口函数参数
    uint32_t    timeout;         // 阻塞超时时间
    // ... 其他平台相关字段
} TCB_t;

这里面的每个字段都有大用处：

  • stack_ptr：任务切换时，CPU寄存器的值就保存在这里。切换回来时再恢复，任务就能「无缝衔接」。
  • priority：决定了任务在就绪队列里的排队顺序。优先级高的先跑。
  • state：就是咱们刚才讲的状态机。调度器根据这个字段决定下一步操作。
  • name：别小看这个字段。我调试时全靠它区分任务，不然一堆数字ID根本记不住。

关键点：TCB是操作系统内核中最频繁访问的数据结构。每次任务切换、状态变更、优先级调整，都要读写TCB。所以它的设计要紧凑、访问要快。我一般把它放在内部RAM里，并且用__attribute__((aligned(4)))对齐，避免访问效率损失。

2.5 任务栈——一个容易踩坑的地方

说到TCB，就不得不提栈。每个任务都有自己的栈空间，大小在创建任务时指定。

我记得有一次，一个同事把任务栈设得太小，结果任务一运行就栈溢出，把相邻的TCB数据给覆盖了。系统跑着跑着就崩溃，查了三天才找到原因。

所以我的建议是：

  • 任务栈大小至少给256字节（对于简单任务）
  • 复杂任务（有大量局部变量或函数调用层级深）给512-1024字节
  • 在调试阶段，开启栈溢出检测功能

避坑指南：我曾经在STM32上遇到过一个问题——任务栈明明够大，但一跑就进HardFault。后来发现是中断嵌套太深，把栈给撑爆了。记住：中断也占用任务栈空间！

2.6 任务创建与销毁

最后，咱们看看任务是怎么生出来的：

// 创建任务
TCB_t task_tcb;
os_task_create(&task_tcb,      // TCB指针
               "led_task",     // 任务名
               led_task_func,  // 入口函数
               NULL,           // 参数
               128,            // 栈大小（单位：字）
               5);             // 优先级（0最高，255最低）

// 启动调度器（开始多任务调度）
os_scheduler_start();

任务创建时，内核会做三件事：

  1. 分配并初始化TCB
  2. 分配栈空间，并初始化栈（放入初始寄存器值）
  3. 把任务加入就绪队列

至于任务销毁，我一般不建议动态销毁任务。因为释放栈空间和TCB容易产生内存碎片。更好的做法是让任务自己退出，或者用挂起状态让它「休眠」。

好了，任务模型和状态机这部分就讲到这里。记住：理解状态机是调试的基础，TCB是操作系统的核心数据结构。下次遇到任务不跑的问题，先查状态，再看TCB，问题基本就能定位了。

公众号:蓝海资料掘金营，微信deep3321

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