任务创建与删除：从新手到老手的必经之路

任务创建和删除，是RTOS里最基础的操作。但说实话，很多人用了好几年，也没完全搞明白里面的门道。我刚开始做嵌入式时，觉得不就是调个API嘛，后来踩了坑才明白——这里头的水，深着呢。

今天咱们就聊聊任务创建API怎么设计、栈怎么分配、删除时资源怎么回收，还有句柄管理那些事儿。嗯，都是实战中摸爬滚打出来的经验。

任务创建API设计：别小看这个接口

任务创建API，说白了就是告诉内核：“嘿，我要跑一个新任务了！”但怎么设计这个接口，直接决定了你的RTOS好不好用。

我个人习惯，任务创建API至少需要这几个参数：

  • 任务函数指针：任务要执行的代码入口
  • 任务名称：调试时方便识别，我一般用字符串
  • 栈大小：给任务分配多少栈空间
  • 优先级：任务在调度队列里的地位
  • 任务参数：传给任务函数的参数指针
  • 任务句柄：返回给调用者，用于后续操作

举个例子，一个典型的API原型长这样：

typedef void (*task_func_t)(void *param);

typedef struct {
    task_func_t   func;        // 任务函数
    const char   *name;        // 任务名称
    uint32_t      stack_size;  // 栈大小（字节）
    uint8_t       priority;    // 优先级（0最高）
    void         *param;       // 任务参数
} task_create_t;

int task_create(task_handle_t *handle, const task_create_t *config);

你想想看，为什么要把参数打包成一个结构体？

我在项目中遇到过，早期版本API参数太多，调用时经常搞混顺序。后来改成结构体，可读性好了很多，扩展也方便——加个新字段不影响旧代码。

小技巧：API返回值用int，0表示成功，负数表示错误码。别用布尔值，调试时错误码能救命。

任务栈分配策略：给多少才够？

栈分配，是RTOS里最容易出问题的地方。给多了浪费内存，给少了直接崩给你看。

我记得有一次，产品在实验室跑得好好的，到客户现场就随机死机。查了三天，最后发现是某个任务的栈溢出了——嗯，那感觉，酸爽。

栈分配的核心原则：够用就好，留点余量。

具体怎么算？我一般这么干：

  1. 静态分析：看任务函数的局部变量、函数调用深度。每个函数调用大概占多少栈，心里要有数。
  2. 动态监测：运行时用栈水印（Stack Watermark）技术，在栈底填充固定模式，定期检查有没有被覆盖。
  3. 经验值：简单任务256字节起步，带点复杂逻辑的512字节，有大量局部数组的至少1KB。

分配方式有两种：

分配方式 优点 缺点
静态分配（编译时） 速度快，无碎片 灵活性差，内存利用率低
动态分配（运行时） 灵活，按需分配 可能产生碎片，分配失败要处理

我个人更倾向静态分配。为什么？因为嵌入式系统里，确定性比灵活性更重要。你想想看，一个医疗设备在手术中突然分配失败——这后果谁担得起？

注意：动态分配时，一定要检查返回值！我曾经见过一个项目，malloc返回NULL没检查，系统跑了三天才崩溃，查得人想哭。

任务删除与资源回收：善后工作不能马虎

任务删除，不是简单地把任务从调度队列里移除就完事了。资源回收才是重头戏。

一个任务可能占用了哪些资源？

  • 栈空间（如果是动态分配的）
  • TCB（任务控制块）
  • 持有的信号量、互斥锁
  • 动态分配的内存
  • 打开的文件描述符
  • 定时器

删除任务时，这些资源都得还回去。不然就是内存泄漏，跑着跑着系统就挂了。

我设计的删除流程是这样的：

int task_delete(task_handle_t handle) {
    // 1. 检查句柄有效性
    if (!is_valid_handle(handle)) return -EINVAL;
    
    // 2. 从就绪队列移除
    remove_from_ready_list(handle);
    
    // 3. 释放持有的资源
    release_owned_resources(handle);
    
    // 4. 释放栈空间（如果是动态分配）
    if (handle->stack_is_dynamic) {
        free(handle->stack_ptr);
    }
    
    // 5. 释放TCB
    free_tcb(handle);
    
    // 6. 句柄置为无效
    invalidate_handle(handle);
    
    return 0;
}

这里有个坑：任务不能删除自己。为什么？因为删除自己的时候，栈还在用，一释放就崩了。正确的做法是：任务请求删除自己，由别的任务或内核来执行删除操作。

核心要点：任务删除后，所有占用的资源必须全部回收。漏一个，就是一颗定时炸弹。

任务句柄管理：别丢了你的钥匙

任务句柄，就像你家的钥匙。有了它，你才能操作这个任务——挂起、恢复、删除、设置优先级等等。

句柄怎么设计？我见过几种方案：

  • 指针直接指向TCB：简单粗暴，但容易被误用
  • 索引值：指向TCB数组的下标，安全性好一点
  • 句柄表：类似文件描述符，内核维护一张表，用户拿到的只是个整数

我个人推荐句柄表方案。为什么？

第一，安全性高。用户拿不到TCB指针，就不能乱改内核数据结构。第二，方便做权限控制。第三，句柄可以复用，TCB释放后句柄还能用，但指向的是空。

句柄表的设计大概这样：

#define MAX_TASKS 64
#define HANDLE_INVALID 0xFFFFFFFF

typedef struct {
    bool          used;        // 这个槽位是否被占用
    task_tcb_t   *tcb;         // 指向实际的TCB
    uint32_t      generation;  // 世代号，防止句柄重用问题
} handle_entry_t;

static handle_entry_t handle_table[MAX_TASKS];

task_handle_t allocate_handle(task_tcb_t *tcb) {
    for (int i = 0; i < MAX_TASKS; i++) {
        if (!handle_table[i].used) {
            handle_table[i].used = true;
            handle_table[i].tcb = tcb;
            // 句柄 = 索引 + 世代号左移
            return (i) | (handle_table[i].generation << 16);
        }
    }
    return HANDLE_INVALID;
}

你可能会问，世代号是干嘛用的？

嗯，这是个好问题。假设任务A被删除了，句柄释放。然后新任务B创建，恰好用了同一个索引。如果用户手里还拿着旧句柄，操作的就是任务B——这bug查起来能让人崩溃。世代号就是防止这种“句柄重用”问题的。

避坑指南：我曾经在句柄验证上偷懒，结果线上出了个诡异bug——一个任务莫名其妙被另一个任务控制了。后来加了世代号验证，再也没出过类似问题。

总结一下

任务创建和删除，看似简单，实则处处是坑。API设计要简洁易用，栈分配要精准留余量，删除时要彻底回收资源，句柄管理要防重用防误操作。

这些经验，都是我在一个个不眠之夜、一次次系统崩溃中换来的。希望你能少走些弯路。

下节课，咱们聊聊任务调度——RTOS的心脏是怎么跳动的。

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