📚 课程目录第3章任务优先级与调度策略

3. 任务优先级与调度策略：抢占式调度与时间片轮转、优先级反转问题与优先级继承协议、空闲任务与钩子函数

调度策略，说白了就是RTOS决定“下一个该谁跑”的规则。很多初学者觉得这不过是设个优先级数字，但我在项目中踩过的坑告诉我——调度策略选不对，系统跑起来就跟开手动挡车在坡起时熄火一样，难受得很。

这一章我们聚焦三个核心话题：抢占式调度和时间片轮转怎么选、优先级反转这个经典问题怎么解、以及那个看似不起眼却至关重要的空闲任务。

3.1 抢占式调度 vs 时间片轮转

先问个问题：你的系统里，任务A在跑，任务B优先级更高，这时候谁来抢？

抢占式调度的答案是：高优先级任务就绪后，立刻打断当前任务。我习惯把这个机制叫做“插队模式”。

抢占式调度的核心特征：

每个任务有固定优先级
高优先级任务就绪时，立即抢占CPU
同优先级任务按FIFO或时间片轮转执行
响应时间可预测，适合实时系统

时间片轮转则不同。它不关心优先级，每个任务轮流跑固定时长。我见过有人把时间片轮转用在电机控制里，结果一个任务跑超时，另一个任务就错过了采样窗口——嗯，电机抖得像跳舞。

特性	抢占式调度	时间片轮转
优先级支持	完整支持	通常不支持或弱支持
响应确定性	高	低
CPU利用率	较高	可能浪费在轮转切换上
适用场景	实时控制、通信协议栈	批处理、非实时任务
实现复杂度	中等	简单

我个人习惯在工业控制项目里用纯抢占式调度。举个例子，一个数据采集任务优先级设高，它必须每1ms采样一次；而日志记录任务优先级设低，有空再写。如果用了时间片轮转，日志任务跑满时间片时，采样任务就得等——这后果你想想看。

我的经验：大多数RTOS（FreeRTOS、uC/OS-III、RT-Thread）默认就是抢占式调度。如果你需要时间片轮转，通常需要显式配置。别搞混了。

3.2 优先级反转问题与优先级继承协议

优先级反转，这名字听着就让人头疼。我最早遇到这个问题是在一个多传感器数据融合的项目里。三个任务：高优先级任务A（处理传感器数据）、中优先级任务B（通信）、低优先级任务C（写Flash）。

事情是这样的：C先拿到了互斥锁，正在写Flash。A来了，想拿锁，但锁在C手里，A只能等。这时候B就绪了，它不需要锁，直接抢占了C。结果呢？A在等C，C被B抢占了，A反而比B优先级还低——这就是优先级反转。

注意：优先级反转不是理论问题，是真实会发生的。我见过一个项目因为这个问题导致看门狗超时复位，排查了整整三天。

解决方案是什么？优先级继承协议。它的思路很简单：当高优先级任务等待低优先级任务持有的锁时，把低优先级任务的优先级临时提升到高优先级任务的级别。这样低优先级任务就不会被中间优先级任务抢占了。

看一个FreeRTOS的代码示例：

// 创建互斥量（支持优先级继承）
SemaphoreHandle_t xFlashMutex = xSemaphoreCreateMutex();

// 低优先级任务C
void vTaskC(void *pvParameters) {
    for (;;) {
        // 获取互斥量
        if (xSemaphoreTake(xFlashMutex, portMAX_DELAY) == pdTRUE) {
            // 写Flash操作
            flash_write();
            // 释放互斥量
            xSemaphoreGive(xFlashMutex);
        }
    }
}

// 高优先级任务A
void vTaskA(void *pvParameters) {
    for (;;) {
        // 获取互斥量
        if (xSemaphoreTake(xFlashMutex, portMAX_DELAY) == pdTRUE) {
            // 处理传感器数据
            sensor_process();
            xSemaphoreGive(xFlashMutex);
        }
    }
}

注意这里用的是xSemaphoreCreateMutex()而不是xSemaphoreCreateBinary()。前者内置了优先级继承机制，后者没有。我曾经犯过这个错，用二进制信号量代替互斥量，结果优先级反转问题照旧。

优先级继承 vs 优先级天花板：

优先级继承：动态提升，只提升到等待任务的优先级
优先级天花板：静态设定，锁的优先级固定为所有可能使用它的任务中的最高优先级

我个人更倾向优先级继承，因为它更灵活，不会过度提升优先级。

3.3 空闲任务与钩子函数

空闲任务，就是系统里所有任务都阻塞时，RTOS跑的那个任务。它优先级最低，永远就绪。你可能会想：“一个啥也不干的任务，有什么好讲的？”

其实不然。空闲任务是个宝，用好了能解决很多问题。

空闲任务的典型用途：

统计CPU利用率
执行低优先级后台工作（如内存整理）
进入低功耗模式
喂看门狗

钩子函数（Hook Function）是RTOS提供的一个回调机制。在FreeRTOS里，你可以注册一个空闲任务钩子：

// 配置空闲任务钩子
// 在FreeRTOSConfig.h中设置
#define configUSE_IDLE_HOOK 1

// 实现钩子函数
void vApplicationIdleHook(void) {
    // 进入低功耗模式
    __WFI();  // Wait For Interrupt
    
    // 或者统计CPU空闲时间
    static uint32_t idle_count = 0;
    idle_count++;
}

我曾经在一个电池供电的物联网设备里，利用空闲任务钩子实现了深度睡眠。系统大部分时间都在空闲，钩子函数里调用__WFI()，功耗从几十毫安降到了微安级别。嗯，这个优化让电池寿命从3天延长到了3个月。

注意：空闲任务钩子里不能阻塞！不能调用vTaskDelay()或等待信号量。因为空闲任务本身就不能被阻塞，否则系统就死锁了。

还有一个常见用法：用空闲任务统计CPU利用率。思路是记录空闲任务在单位时间内执行了多少次，然后反推出CPU被占用的比例。

// CPU利用率统计
static uint32_t ulIdleCycleCount = 0;

void vApplicationIdleHook(void) {
    ulIdleCycleCount++;
}

uint32_t ulGetCPUUsage(void) {
    uint32_t ulIdleNow = ulIdleCycleCount;
    uint32_t ulTotalTicks = 1000;  // 统计周期
    
    // 假设满负载时空闲计数为0
    // 空闲计数越高，CPU利用率越低
    return (100 - (ulIdleNow * 100 / ulTotalTicks));
}

这个方法虽然粗糙，但在实际项目中够用了。我调试过一个通信协议栈，就是靠这个统计发现某个任务占用了80%的CPU，最后定位到是一个轮询循环没加延时。

空闲任务钩子的避坑指南：

钩子函数要短小精悍，别在里面做复杂计算
不要调用任何可能导致任务切换的API
如果用了低功耗模式，确保中断能唤醒系统
多核系统里，每个核都有自己的空闲任务

下面这张图总结了本章的核心知识结构：

好了，这一章的内容就到这里。调度策略、优先级反转、空闲任务钩子，这三个点在实际调试中经常碰到。下次你遇到任务跑飞或者系统响应慢，不妨先从这三个角度排查一下。