3. 抢占式调度：优先级反转问题与解决方案

各位做嵌入式开发的同行，今天我们来聊一个老生常谈但又特别容易踩坑的问题——优先级反转。说实话，我在麻醉机项目上被这个问题折腾过不止一次。你想想看，一个高优先级的任务，比如呼气阀的紧急关闭，居然被一个低优先级的任务给堵住了，这要是发生在手术中，后果不堪设想。

3.1 什么是优先级反转？

先看一个典型场景。假设我们有三个任务：

• 任务A：高优先级，负责呼气阀紧急关闭（周期5ms）
• 任务B：中优先级，负责UI界面刷新（周期50ms）
• 任务C：低优先级，负责传感器数据采集（周期100ms）

三个任务共享一个互斥锁，保护传感器数据缓冲区。

正常情况下的执行顺序应该是：任务A来了，抢到CPU，干完活走人。但优先级反转发生时，情况就乱了：

1. 任务C先拿到锁，开始读传感器
2. 任务A来了，想拿锁，发现锁被C占着，只能等
3. 任务B来了，它不需要锁，直接抢走CPU——因为B的优先级比C高
4. 任务C被B抢占了，锁一直拿不回来
5. 任务A只能干等着，直到B跑完，C才能继续执行

结果呢？最高优先级的任务A，反而被最低优先级的任务C和中优先级的任务B联手拖死了。这就是优先级反转。

3.2 我在麻醉机项目中遇到的真实案例

我记得有一次做麻醉机的压力控制模块调试。系统里有个压力传感器数据采集任务（优先级低），一个PID控制任务（优先级高），还有一个通信任务（优先级中）。

现象是这样的：麻醉机运行一段时间后，偶尔会出现压力过冲，持续几十毫秒。查了三天，最后用逻辑分析仪抓任务调度时序才发现——PID控制任务被堵了，原因就是优先级反转。

低优先级的采集任务拿着共享的传感器数据锁，被中优先级的通信任务抢占了CPU。PID控制任务虽然优先级最高，但只能干等。那几十毫秒的过冲，就是锁被释放前的等待时间。

3.3 解决方案一：优先级继承

优先级继承的思路很直接——当低优先级任务持有高优先级任务需要的锁时，临时把低优先级任务的优先级提升到高优先级任务的级别。

说白了就是：任务C你拿着锁，任务A在等你，那你就别被任务B欺负了，先让你跑完再说。

实现方式：

// 伪代码示例：优先级继承实现
void mutex_lock(Mutex *m, Task *current) {
    if (m->owner == NULL) {
        // 没人持有锁，直接拿
        m->owner = current;
    } else {
        // 锁被占着，检查是否需要继承优先级
        if (current->priority > m->owner->priority) {
            // 高优先级任务在等，提升持有者的优先级
            m->owner->original_priority = m->owner->priority;
            m->owner->priority = current->priority;
        }
        // 当前任务挂起等待
        current->state = BLOCKED;
    }
}

void mutex_unlock(Mutex *m, Task *current) {
    // 释放锁，恢复原始优先级
    current->priority = current->original_priority;
    m->owner = NULL;
    // 唤醒等待队列中优先级最高的任务
    wake_highest_priority_task(m->wait_queue);
}

优点很明显：实现简单，能有效解决反转问题。缺点呢？可能发生链式继承——多个任务嵌套等待时，优先级会被层层提升，调度分析变得复杂。

3.4 解决方案二：优先级天花板

这个方法更粗暴一些。每个互斥锁都设定一个「天花板优先级」——所有可能访问这个锁的任务中，最高的那个优先级。

任何任务拿到这个锁，优先级立刻被提升到天花板级别。不管有没有高优先级任务在等，先把自己提到最高再说。

// 伪代码示例：优先级天花板实现
#define CEILING_PRIORITY 10  // 该锁的天花板优先级

void mutex_lock_ceiling(Mutex *m, Task *current) {
    // 拿到锁的同时，提升优先级到天花板
    current->original_priority = current->priority;
    current->priority = CEILING_PRIORITY;
    m->owner = current;
}

void mutex_unlock_ceiling(Mutex *m, Task *current) {
    // 释放锁，恢复原始优先级
    current->priority = current->original_priority;
    m->owner = NULL;
}

这个方法的好处是：实现更简单，没有链式继承的问题。坏处是：可能造成不必要的优先级提升。比如任务C拿锁时，任务A根本没在等，但C的优先级还是被提上去了，浪费了CPU资源。

3.5 两种方案的对比

特性	优先级继承	优先级天花板
实现复杂度	中等	简单
CPU开销	低（仅在有竞争时提升）	高（每次拿锁都提升）
死锁风险	低	更低
适用场景	任务数量少，锁竞争不频繁	任务数量多，需要确定性
实时性保障	较好	最好（最坏情况可预测）

3.6 我的选择建议

在麻醉机这类生命支持设备上，我个人更倾向于优先级天花板方案。为什么？因为确定性更重要。

你想想看，手术过程中，麻醉医生需要知道每个控制回路的响应时间上限。优先级继承虽然平均性能好，但最坏情况下的响应时间分析起来很麻烦。优先级天花板虽然浪费一点CPU，但每个锁的等待时间都是确定的，这对安全认证来说太重要了。

最后说一句：不管用哪种方案，一定要在系统设计阶段就把共享资源的访问策略定下来。等到代码写完了再改，那代价就大了。嗯，今天就聊到这里，下一节我们讲中断处理中的实时性保障。