3. 任务类型：基本任务与扩展任务的区别、使用场景对比

在OSEK标准里，任务分两种：基本任务（Basic Task）和扩展任务（Extended Task）。很多初学者容易混淆，觉得不就是多一个等待事件嘛。其实没那么简单。我最早接触OSEK时也踩过坑，以为扩展任务就是基本任务的“升级版”，结果调度器跑起来各种不符合预期。今天咱们把这两个东西彻底掰开揉碎。

3.1 核心区别：能不能“挂起等待”

说白了，最本质的区别就一句话：基本任务不能主动挂起等待事件，扩展任务可以。

你想想看，一个基本任务从开始到结束，要么在运行，要么被抢占，要么自己主动终止。它没有“我在这儿等个信号量”这种状态。而扩展任务多了一个等待态（Waiting），可以调用WaitEvent()把自己挂起来，等某个事件来了再继续跑。

我习惯用一张状态机图来对比，这样更直观：

基本任务 vs 扩展任务 状态机对比 基本任务（Basic Task） 就绪态 运行态 终止态 调度 TerminateTask() 激活 扩展任务（Extended Task） 就绪态 运行态 终止态 等待态 调度 TerminateTask() 激活 WaitEvent() SetEvent() 关键差异 • 基本任务只有 3 个状态：就绪、运行、终止 • 扩展任务有 4 个状态：就绪、运行、终止、等待 • 扩展任务通过 WaitEvent() 进入等待态，通过 SetEvent() 回到就绪态 • 基本任务不能等待，必须一口气跑到 TerminateTask()

一句话总结：基本任务适合“拿来就干，干完就走”的场景；扩展任务适合“需要等某个条件满足才能继续”的场景。

3.2 详细对比表格

我把两个任务类型的差异整理成了一张表，方便你对照查阅：

对比维度 基本任务（Basic Task） 扩展任务（Extended Task）
状态数 3个（就绪、运行、终止） 4个（就绪、运行、终止、等待）
能否等待事件 ❌ 不能 ✅ 可以，通过 WaitEvent()
堆栈需求 较小（无需保存等待上下文） 较大（需要保存等待态上下文）
调度开销 低 相对较高
典型用途 周期性采样、简单计算、状态更新 等待外部事件、信号量同步、多条件触发
资源占用 少 多（每个扩展任务需要独立的等待队列）
可嵌套调用 不支持嵌套等待 支持事件嵌套等待

我的经验：在项目初期规划任务时，我习惯先问自己一个问题——“这个任务需不需要等什么东西？”如果答案是“不需要”，我优先用基本任务。因为基本任务简单、轻量、不容易出调度问题。我曾经在一个项目里把所有任务都设成扩展任务，结果堆栈爆了，排查了半天才发现是等待态上下文保存太多。

3.3 使用场景对比

3.3.1 什么时候用基本任务？

基本任务适合那些“拿来就干，干完就走”的场景。我总结了几种典型情况：

  • 周期性采样任务：比如每10ms读取一次传感器数据，处理完就结束。不需要等任何东西。
  • 简单状态更新：比如把某个计算结果写到一个全局变量里，其他任务去读。
  • 纯计算任务：比如做一次CRC校验、滤波计算，算完就完事。
  • 触发式动作：比如某个中断来了，激活一个基本任务去处理，处理完就终止。

举个例子，一个简单的ADC采样任务：

// 基本任务：每10ms读取一次ADC值
TASK(AdcSampleTask)
{
    uint16 adcValue;
    
    adcValue = Adc_ReadChannel(ADC_CHANNEL_1);
    g_CurrentAdcValue = adcValue;  // 更新全局变量
    
    TerminateTask();  // 干完就走
}

你看，这个任务没有等待，没有阻塞，进来干活，干完走人。用基本任务再合适不过。

3.3.2 什么时候用扩展任务？

扩展任务适合那些“需要等某个条件满足才能继续”的场景。我遇到过的情况包括：

  • 等待多个事件：比如一个任务要等“数据准备好”和“DMA传输完成”两个事件都到了才能继续。
  • 信号量同步：比如两个任务需要同步执行某个操作，一个任务等另一个任务发信号。
  • 复杂状态机：比如一个任务在不同阶段等待不同的事件，用扩展任务可以优雅地实现。
  • 资源等待：比如等某个共享资源被释放，再继续往下走。

举个例子，一个等待CAN消息的任务：

// 扩展任务：等待CAN消息到达
TASK(CanReceiveTask)
{
    EventMaskType event;
    
    // 等待CAN接收事件
    WaitEvent(EVENT_CAN_RX);
    
    // 获取具体事件
    GetEvent(CanReceiveTask, &event);
    
    if (event & EVENT_CAN_RX)
    {
        Can_ReadMessage(&g_CanRxMsg);
        ClearEvent(EVENT_CAN_RX);
    }
    
    TerminateTask();
}

这个任务平时就挂在等待态，不占CPU。等CAN中断来了，通过SetEvent()把它唤醒，它才继续执行。这就是扩展任务的典型用法。

注意：扩展任务虽然灵活，但不要滥用。每个扩展任务在等待态时都需要保存完整的上下文，堆栈开销比基本任务大不少。我曾经在一个项目里看到有人把20个任务都设成扩展任务，结果RAM直接爆了。后来我帮他把其中15个改成基本任务，RAM占用降了40%。

3.4 选择决策流程

在实际项目中，我习惯用下面这个简单的决策流程来判断该用哪种任务：

任务类型选择决策流程 开始设计任务 需要等待事件？ 基本任务 轻量、快速、低开销 扩展任务 灵活、可等待、开销大 RAM够用？ 确认使用 重新设计架构

我的建议：如果你不确定该用哪种，先试试基本任务。基本任务搞不定再换成扩展任务。我见过太多人一上来就用扩展任务，结果调度器跑起来各种奇怪问题。记住：能用基本任务解决的问题，就不要用扩展任务。

3.5 避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路：

  • 不要在基本任务里调用WaitEvent()——这会导致系统崩溃。我刚开始学OSEK时犯过这个错，调试了一整天才发现。
  • 扩展任务不要等太久——如果一个扩展任务长时间处于等待态，要考虑是否会影响其他任务的调度。我曾经有个任务等了500ms，结果导致一个高优先级任务错过了deadline。
  • 注意堆栈分配——扩展任务的堆栈需求比基本任务大，因为要保存等待态的上下文。我习惯给扩展任务多分配20%-30%的堆栈空间。
  • 不要滥用事件——如果一个任务要等10个事件，那可能说明你的任务划分有问题。考虑拆分成多个小任务。

曾经踩过的坑：有一次我把一个CAN接收任务设成了基本任务，结果因为CAN消息来得太快，任务还没跑完就被再次激活，导致数据覆盖。后来改成扩展任务，用事件来同步，问题就解决了。所以选型时要考虑实际场景，不能一概而论。

嗯，基本任务和扩展任务的区别就讲到这里。记住核心原则：基本任务简单高效，扩展任务灵活但开销大。选型时多想想你的实际需求，别盲目追求“功能强大”。

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