📚 课程目录第4章实时任务调度与优先级反转

4. 实时任务调度与优先级反转：任务创建与删除、优先级配置、互斥量与信号量、优先级反转案例分析与解决方案

各位工程师，咱们今天聊一个在医疗设备开发中绕不开的话题——实时任务调度。说实话，很多刚入行的朋友觉得任务调度不就是调个优先级嘛，有什么难的？直到你遇到一次莫名其妙的系统卡顿，或者某个传感器数据突然丢失，你才会意识到，这里面的水其实挺深的。

我个人习惯把实时调度比作医院急诊室的排队机制。每个任务就像一位病人，优先级决定了谁先被处理。但问题来了——如果一位低优先级的病人占着CT机不放，高优先级的病人只能干等着，这就是典型的优先级反转。在医疗设备里，这可不是闹着玩的。

4.1 任务创建与删除：基础操作里的坑

先说说任务创建。在FreeRTOS或uC/OS-III里，创建任务无非就是调用一个API。但我在项目中遇到过一个问题：某次给呼吸机写控制程序，任务创建时忘了检查返回值，结果系统跑着跑着突然少了一个任务，病人端的压力数据直接断了。

// 正确的任务创建姿势
TaskHandle_t xTaskHandle = NULL;
BaseType_t xReturned = xTaskCreate(
    vTaskFunction,       // 任务函数
    "SensorTask",        // 任务名称
    configMINIMAL_STACK_SIZE * 2, // 栈深度，我建议至少给2倍
    NULL,                // 参数
    tskIDLE_PRIORITY + 2, // 优先级
    &xTaskHandle         // 任务句柄
);

// 一定要检查返回值！
if (xReturned != pdPASS) {
    // 记录错误日志，触发安全状态
    vEnterSafeMode();
}

⚠️ 避坑指南：我曾经在一个输液泵项目里，因为任务栈分配不足，导致任务在运行几个小时后栈溢出，系统直接复位。从那以后，我每个任务的栈大小都至少给到理论值的1.5倍，并且在调试阶段开启栈溢出检测。

任务删除呢？很多人觉得调用vTaskDelete(NULL)就完事了。但你想想看，如果这个任务正握着一个互斥量，或者正操作一个共享缓冲区，你直接把它删了，资源就永远释放不了了。我建议的做法是：先发一个删除请求，让任务自己清理资源，再自我删除。

4.2 优先级配置：不是越高越好

优先级配置是门艺术。很多新手喜欢把所有关键任务都设成最高优先级，结果系统里全是高优先级任务在抢CPU，低优先级任务永远得不到执行。说白了，这就是优先级饥饿。

我一般遵循一个原则：优先级只反映任务的紧急程度，不反映任务的重要性。比如在除颤仪里，心电采集任务可以设高优先级（因为它有实时性要求），但日志记录任务设低优先级就够了。

任务类型	推荐优先级	说明
安全监控任务	最高（如5）	检测过压、过流、系统异常
实时控制任务	高（如4）	PID控制、电机驱动
数据采集任务	中高（如3）	传感器读取、AD转换
通信任务	中（如2）	CAN、UART、SPI
日志/显示任务	低（如1）	LCD刷新、SD卡写入

💡 个人经验：我习惯在系统启动时动态计算优先级。比如根据任务的周期和截止时间，用速率单调调度（RMS）算法来分配。这样比拍脑袋设优先级靠谱得多。

4.3 互斥量与信号量：一字之差，天壤之别

这两个东西经常被混淆。我简单说：信号量是通知机制，互斥量是保护机制。

信号量就像是一个令牌。任务A拿到令牌才能继续，用完再还回去。它适合做同步，比如一个任务等数据准备好了再处理。

互斥量呢？它自带一个优先级继承机制。什么意思？如果一个低优先级任务拿着互斥量，高优先级任务来等这个互斥量时，系统会临时把低优先级任务的优先级提升到和高优先级一样，这样它就能尽快执行完释放互斥量。这个机制就是为了防止优先级反转的。

// 互斥量使用示例
SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

void vTaskHigh(void *pvParameters) {
    // 高优先级任务
    if (xSemaphoreTake(xMutex, pdMS_TO_TICKS(100)) == pdTRUE) {
        // 访问共享资源
        vWriteToSensorBuffer();
        xSemaphoreGive(xMutex);
    } else {
        // 超时处理，不能死等
        vLogError("Mutex timeout");
    }
}

void vTaskLow(void *pvParameters) {
    // 低优先级任务
    xSemaphoreTake(xMutex, portMAX_DELAY);
    // 长时间操作...
    vProcessData();
    xSemaphoreGive(xMutex);
}

🔑 关键区别：互斥量只能用于任务间，不能用于中断。信号量可以用于中断和任务之间。另外，互斥量有递归版本（Recursive Mutex），允许同一个任务多次获取同一个互斥量，这在函数嵌套调用时很有用。

4.4 优先级反转：经典案例与解决方案

优先级反转是实时系统里最经典的坑之一。我讲一个真实案例：某款监护仪，三个任务——高优先级的报警任务、中优先级的UI刷新任务、低优先级的网络通信任务。正常情况下没问题，但一旦网络通信任务拿到互斥量后，UI刷新任务抢占了CPU，报警任务就只能等着。结果就是：病人心率异常了，报警延迟了好几秒才响。

为什么会这样？因为低优先级任务拿着互斥量，被中优先级任务抢占，高优先级任务拿不到互斥量，只能等低优先级任务执行完。但低优先级任务又被中优先级任务卡住了，形成了一个死锁链。

解决方案呢？我常用的有三种：

优先级继承：使用互斥量（带优先级继承的版本），低优先级任务在持有互斥量期间临时提升优先级。
优先级天花板：给每个互斥量设一个天花板优先级，任何任务拿到这个互斥量后，优先级自动提升到天花板级别。
关中断法：对于非常短的临界区，直接关中断保护。但注意，关中断时间不能超过系统允许的最大延迟。

💡 我的建议：在医疗设备里，我优先使用互斥量的优先级继承机制。它不需要你手动计算天花板优先级，系统自动处理。但要注意，优先级继承只能解决直接反转，不能解决链式反转。对于链式反转，你需要用优先级天花板协议。

最后说一句，调试优先级反转问题，最好的工具就是RTOS自带的跟踪功能。我习惯在系统里加一个任务状态监控任务，每隔一段时间打印所有任务的状态和优先级。一旦发现某个高优先级任务长时间处于阻塞状态，就重点排查它等待的资源。