📚 课程目录第4章优先级调度算法

4. 优先级调度算法：固定优先级调度（FPS）、优先级反转问题、优先级继承协议

好，咱们今天聊一个非常核心的话题——优先级调度。说白了，就是决定“哪个任务先跑”的规则。你想想看，一个系统里同时有十几个任务在等着CPU，谁先谁后？这可不是随便排个队就能解决的。

我个人习惯把优先级调度比作“急诊室分诊”。心跳骤停的病人（高优先级任务）必须立刻抢救，哪怕后面排着几十个感冒发烧的（低优先级任务）。但问题来了——如果抢救需要一台呼吸机，而呼吸机正好被一个感冒病人占着……嗯，这就是我们要讲的优先级反转。

4.1 固定优先级调度（FPS）

固定优先级调度，英文叫 Fixed-Priority Scheduling，简称 FPS。它的核心思想很简单：每个任务在系统启动时就分配一个固定的优先级，运行过程中优先级不变。

我在项目中遇到过不少团队，一上来就想搞动态优先级，觉得“自适应”才高级。但说实话，对于大多数嵌入式系统，FPS 已经够用了。而且它实现简单、可预测性强，调试起来也省心。

4.1.1 FPS 的基本规则

优先级分配：每个任务有一个唯一的优先级数值（通常数值越小优先级越高，或反之，取决于RTOS实现）。
抢占规则：高优先级任务就绪时，立即抢占正在运行的低优先级任务。
同优先级任务：通常采用时间片轮转或FIFO调度。

关键点：FPS 的可调度性分析有成熟的数学工具——响应时间分析（Response Time Analysis, RTA）。这是我在做航空电子项目时最常用的方法，比单纯靠“感觉”分配优先级靠谱得多。

4.1.2 优先级分配策略

优先级怎么分？我见过三种常见策略：

策略	描述	适用场景
速率单调（RM）	周期越短，优先级越高	周期性任务集，任务周期已知
截止时间单调（DM）	截止时间越短，优先级越高	任务截止时间与周期不同
人工分配	根据任务重要性手动指定	任务数量少，或对实时性有特殊要求

我个人偏爱 RM 策略。为什么？因为它有理论支撑——如果任务集在 RM 下是可调度的，那么任何其他固定优先级分配方式也一定是可调度的。说白了，RM 是最优的固定优先级分配策略。

小提示：RM 的利用率上界是 n(2^(1/n) - 1)。当任务数 n→∞ 时，上界趋近于 ln2 ≈ 0.693。也就是说，如果 CPU 利用率超过 69.3%，RM 就不能保证所有任务都能满足截止时间了。

4.2 优先级反转问题

好，现在咱们聊一个经典问题——优先级反转。这玩意儿我当年第一次遇到时，差点把板子砸了。

什么叫优先级反转？简单说：一个高优先级任务被一个低优先级任务阻塞，而中优先级任务却可以正常运行。这完全违背了优先级调度的初衷。

4.2.1 典型场景

假设有三个任务：

任务H：高优先级，需要访问共享资源 R
任务M：中优先级，不需要访问 R
任务L：低优先级，已经占用了资源 R

执行流程是这样的：

任务L 开始运行，获取资源 R 的锁。
任务H 就绪，抢占任务L。但任务H 需要资源 R，发现锁被任务L 持有，于是阻塞。
任务L 继续运行，准备释放锁。
任务M 就绪，抢占任务L（因为任务M 优先级高于任务L）。
任务M 运行，任务L 被挂起，任务H 继续等待。

看到了吗？任务H 明明优先级最高，却被任务M 间接阻塞了。这就是优先级反转。

警告：优先级反转最可怕的地方在于——阻塞时间不可预测。如果中间有多个中优先级任务，任务H 可能被阻塞任意长时间。我曾经在一个工业控制项目中遇到过这种情况，导致一个关键的报警任务延迟了 200ms，差点酿成事故。

4.2.2 优先级反转的后果

后果	说明
截止时间错过	高优先级任务无法在规定时间内完成
系统抖动	任务响应时间变得不可预测
死锁风险	多个任务互相等待资源，形成死循环
调试困难	问题复现条件苛刻，难以定位根因

4.3 优先级继承协议

怎么解决优先级反转？最经典的方法就是优先级继承协议（Priority Inheritance Protocol, PIP）。

核心思想：当低优先级任务阻塞了高优先级任务时，低优先级任务临时“继承”高优先级任务的优先级，直到释放资源。

4.3.1 工作原理

还是刚才那个例子，加上优先级继承后：

任务L 运行，获取资源 R 的锁。
任务H 就绪，抢占任务L。但任务H 需要资源 R，发现锁被任务L 持有，于是阻塞。
关键步骤：任务L 临时继承任务H 的优先级，变成最高优先级。
任务M 就绪，但无法抢占任务L（因为任务L 现在优先级比任务M 高）。
任务L 继续运行，释放资源 R，优先级恢复原值。
任务H 获取资源 R，开始运行。

你看，任务H 只被阻塞了任务L 释放资源的时间，而不是被中优先级任务无限拖延。

核心要点：优先级继承只发生在“低优先级任务持有高优先级任务需要的资源”时。继承的优先级等于所有被阻塞任务中的最高优先级。

4.3.2 优先级继承 vs. 优先级天花板

除了优先级继承，还有一种协议叫优先级天花板协议（Priority Ceiling Protocol, PCP）。我简单对比一下：

特性	优先级继承（PIP）	优先级天花板（PCP）
实现复杂度	较低	较高
死锁预防	不能预防死锁	可以预防死锁
阻塞时间	可能发生链式阻塞	最多阻塞一次
典型应用	大多数RTOS（如FreeRTOS、uC/OS）	对死锁敏感的航空/医疗系统

我个人在大多数项目中都用优先级继承。为什么？因为它实现简单，而且大多数商用RTOS都原生支持。但如果你做的是安全关键系统（比如飞控），我建议用优先级天花板——虽然复杂一点，但能彻底避免死锁。

4.3.3 代码示例：FreeRTOS 中的优先级继承

FreeRTOS 的互斥量（Mutex）默认支持优先级继承。看个例子：

// 创建互斥量
SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

// 任务L（低优先级）
void TaskL(void *pvParameters) {
    while(1) {
        // 获取互斥量
        if(xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
            // 访问共享资源
            processResource();
            // 释放互斥量
            xSemaphoreGive(xMutex);
        }
        // 其他工作
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

// 任务H（高优先级）
void TaskH(void *pvParameters) {
    while(1) {
        // 获取互斥量
        if(xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
            // 访问共享资源
            processResource();
            // 释放互斥量
            xSemaphoreGive(xMutex);
        }
        // 其他工作
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

注意：FreeRTOS 的二进制信号量（Binary Semaphore）不支持优先级继承。如果你用信号量做互斥，优先级反转问题依然存在。所以，互斥一定要用 Mutex，不要用 Binary Semaphore。这是我踩过的坑，分享给你。

4.4 知识体系总览

为了让你更直观地理解本章的知识结构，我画了一张图：

4.5 避坑指南

最后，分享几个我踩过的坑：

不要用 Binary Semaphore 做互斥：它不支持优先级继承，优先级反转问题会直接暴露。
注意中断上下文：在中断服务函数中不要使用会阻塞的互斥量操作，否则系统可能直接崩溃。
优先级不要太多：我见过有人分了32级优先级，结果调试时自己都搞不清谁高谁低。一般来说，8-16级足够了。
测试要覆盖反转场景：优先级反转问题在低负载时很难复现，一定要构造高负载测试用例。

曾经有一次，我在一个医疗设备项目中，因为用了 Binary Semaphore 做互斥，导致高优先级的呼吸监测任务被低优先级的日志任务阻塞了 500ms。病人数据出现了断层，还好是在测试阶段发现的。从那以后，我所有项目的代码规范里都加了一条：互斥必须用 Mutex，禁止使用 Binary Semaphore。

好了，优先级调度这块就聊到这儿。记住一句话：优先级是工具，不是目的。我们的目标是让所有任务在截止时间前完成，而不是让高优先级任务永远跑在最前面。