如何解决FreeRTOS信号量使用中出现的优先级反转问题？

#include "FreeRTOS.h"
#include "semphr.h"

SemaphoreHandle_t xMutex; // 互斥信号量句柄

// 低优先级任务：持有互斥量
void vLowPriorityTask(void *pvParam) {
    for (;;) {
        xSemaphoreTake(xMutex, portMAX_DELAY); // 获取锁
        // 临界区操作（尽量简短）
        vTaskDelay(pdMS_TO_TICKS(100)); // 模拟资源使用
        xSemaphoreGive(xMutex); // 释放锁
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

// 中优先级任务：无锁操作，可能抢占CPU
void vMediumPriorityTask(void *pvParam) {
    for (;;) {
        // 无锁操作，持续运行会抢占低优先级任务
        vTaskDelay(pdMS_TO_TICKS(50));
    }
}

// 高优先级任务：等待互斥量
void vHighPriorityTask(void *pvParam) {
    for (;;) {
        xSemaphoreTake(xMutex, portMAX_DELAY); // 等待锁
        // 高优先级任务操作资源
        printf("High priority task running\n");
        xSemaphoreGive(xMutex); // 释放锁
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main(void) {
    xMutex = xSemaphoreCreateMutex(); // 创建互斥信号量
    if (xMutex) {
        // 创建任务：高优先级(3) > 中优先级(2) > 低优先级(1)
        xTaskCreate(vLowPriorityTask, "Low", 128, NULL, 1, NULL);
        xTaskCreate(vMediumPriorityTask, "Medium", 128, NULL, 2, NULL);
        xTaskCreate(vHighPriorityTask, "High", 128, NULL, 3, NULL);
        vTaskStartScheduler();
    }
    for (;;);
}

效果

当低优先级任务持有互斥量时，若高优先级任务等待该锁，低优先级任务的优先级会临时提升至 3（与高优先级任务相同），避免被中优先级任务（优先级 2）抢占。
低优先级任务释放锁后，优先级自动恢复为 1，系统回到正常调度。

二、优先级天花板（Priority Ceiling）

原理

优先级天花板机制是另一种解决优先级反转的策略：为共享资源设置一个固定的 “天花板优先级”（通常等于可能访问该资源的最高优先级任务的优先级）。当任何任务获取该资源时，其优先级会被提升至天花板优先级，直到释放资源。

实现方式

FreeRTOS 本身未直接提供优先级天花板 API，但可通过以下方式模拟：

为资源定义天花板优先级（如 configMAX_PRIORITIES - 1）。
任务获取资源前，调用 vTaskPrioritySet() 提升自身优先级至天花板。
释放资源后，恢复原优先级。

示例代码

void vTaskUsingResource(void *pvParam) {
    UBaseType_t uxOriginalPriority = uxTaskPriorityGet(NULL); // 保存原优先级
    const UBaseType_t uxCeilingPriority = 3; // 天花板优先级（最高任务优先级）

    for (;;) {
        // 获取资源前提升优先级至天花板
        vTaskPrioritySet(NULL, uxCeilingPriority);
        xSemaphoreTake(xSemaphore, portMAX_DELAY);

        // 临界区操作
        vTaskDelay(pdMS_TO_TICKS(100));

        // 释放资源并恢复原优先级
        xSemaphoreGive(xSemaphore);
        vTaskPrioritySet(NULL, uxOriginalPriority);

        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

特点

比优先级继承更激进，能完全避免反转，但可能导致更多任务优先级被不必要提升，影响系统响应性。
适用于资源访问频繁且优先级明确的场景。

三、缩短临界区长度

原理

优先级反转的影响程度与低优先级任务持有资源的时间成正比。若能将临界区（持有信号量的代码段）缩短至极致，即使发生反转，高优先级任务的等待时间也可忽略不计。

实践建议

仅在必要时持有信号量，资源操作完成后立即释放。
将非必要操作（如打印、延迟）移出临界区。
用更高效的算法优化临界区代码。

反面示例（需避免）

// 错误：临界区包含非必要操作
xSemaphoreTake(xMutex, portMAX_DELAY);
processData(); // 必要操作
printf("Data processed\n"); // 非必要操作（耗时）
vTaskDelay(pdMS_TO_TICKS(50)); // 错误：持有锁时延迟
xSemaphoreGive(xMutex);

正确示例

// 正确：缩短临界区
xSemaphoreTake(xMutex, portMAX_DELAY);
processData(); // 仅保留必要操作
xSemaphoreGive(xMutex);

// 非必要操作移至临界区外
printf("Data processed\n");
vTaskDelay(pdMS_TO_TICKS(50));

四、避免多任务嵌套使用信号量

原理

多个信号量的嵌套使用会增加优先级反转的概率和复杂度（如 “优先级链”）。例如：任务 A（高）等待任务 B（中）的锁，任务 B 等待任务 C（低）的锁，形成多级反转。

规避方法

减少信号量的嵌套使用，尽量用一个信号量保护一组相关资源。
若必须嵌套，确保所有任务按相同顺序获取信号量（如先获取 S1，再获取 S2），避免循环等待。

总结：解决方案对比与选择

方法	原理	优势	劣势	适用场景
互斥信号量（推荐）	动态继承优先级	自动处理，对系统影响小	仅适用于互斥场景，不能在中断中使用	大多数共享资源互斥场景
优先级天花板	固定提升至最高优先级	完全避免反转，实现简单	可能过度提升优先级，影响其他任务	资源访问频繁且优先级明确的场景
缩短临界区	减少持有资源的时间	无额外机制开销，兼容性好	仅缓解问题，无法彻底解决	临界区本身可优化的场景
避免嵌套信号量	减少反转链的形成	降低系统复杂度	对任务设计有约束	多资源访问场景