FreeRTOS学习笔记 17：资源管理与临界区保护——优先级反转、死锁，90%的RTOS bug都跟它有关

FreeRTOS资源管理深度解析：临界区保护、挂起调度器、互斥量优先级继承机制，含死锁排查和面试考点，附可运行代码。

前面16篇笔记把FreeRTOS的核心模块几乎都讲了一遍------任务、队列、信号量、事件、定时器、内存、中断、低功耗、调度器内部机制......但有一类bug，90%的RTOS初学者都会遇到，而且排查起来极其痛苦：两个任务抢同一个变量，偶尔出bug，没法稳定复现。

这就是资源管理的问题。这篇文章把 FreeRTOS 中保护共享资源的四种方法一次性讲透。

---

一、问题场景：一个经典的竞态条件Bug

1.1 先看一段有bug的代码

假设有两个任务，任务A每次给 sharedCounter 加1，任务B每次减1：

volatile int sharedCounter = 100;  /* 共享资源 */

void vTaskA(void *pvParameters) {
    for (;;) {
        sharedCounter++;            /* 读-改-写 */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void vTaskB(void *pvParameters) {
    for (;;) {
        sharedCounter--;            /* 读-改-写 */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

为什么有bug？

/* sharedCounter++ 翻译成汇编，不是原子操作： */
    LDR  r0, [pc, #offset]    /* 1. 从内存加载到寄存器 */
    ADD  r0, r0, #1           /* 2. 寄存器加1        */
    STR  r0, [pc, #offset]    /* 3. 写回内存          */

时序图------当两个任务同时操作时：

任务A (优先级1):           LDR r0, [counter]  → r0 = 100
任务B (优先级2，抢占):     LDR r0, [counter]  → r0 = 100
                          ADD r0, r0, #1     → r0 = 101
                          STR r0, [counter]  → counter = 101
任务A (继续):              ADD r0, r0, #1     → r0 = 101  ← 用的还是旧值！
                          STR r0, [counter]  → counter = 101

结果 ：两次操作后 counter 应该是 100+1-1=100，但实际却变成了 101！任务B的减1操作被覆盖了。

这种 bug 的特征是：偶发、难复现、和时序有关------非常折磨人。

---

二、方法1：临界区（Critical Section）

2.1 原理

关闭中断，让这段代码在不可打断的环境中执行。这是最"重"但也是最彻底的保护手段。

void vTaskA(void *pvParameters) {
    for (;;) {
        taskENTER_CRITICAL();      /* 进入临界区------关闭中断 */
        sharedCounter++;           /* 这段代码不会被任何任务或中断打断 */
        taskEXIT_CRITICAL();       /* 退出临界区------恢复中断 */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

2.2 源码剖析

/* task.h 中的实现（Cortex-M3/M4） */
#define taskENTER_CRITICAL()           \
    {                                  \
        UBaseType_t uxCriticalNesting; \
        uxCriticalNesting = portSET_INTERRUPT_MASK_FROM_ISR();  \
        /* 保存当前中断状态，然后关闭所有 maskable 中断 */      \
    }

#define taskEXIT_CRITICAL()            \
    {                                  \
        portCLEAR_INTERRUPT_MASK_FROM_ISR(uxCriticalNesting); \
        /* 恢复到进入前的中断状态 */    \
    }

关键细节 ：临界区支持嵌套 ------每个 taskENTER_CRITICAL 都对应一个 taskEXIT_CRITICAL，通过 uxCriticalNesting 计数器管理。

taskENTER_CRITICAL();       /* nesting = 1，关中断 */
    taskENTER_CRITICAL();   /* nesting = 2，关中断（已经关了，但计数器递增） */
    /* ... */
    taskEXIT_CRITICAL();    /* nesting = 1，还不开中断 */
taskEXIT_CRITICAL();        /* nesting = 0，恢复中断 */

2.3 优缺点

维度	评价
保护力度	⭐⭐⭐⭐⭐ 最彻底
对系统影响	❌ 中断延迟增大，影响实时性
适用范围	极短的保护代码（几微秒）
中断中能用？	❌ 不能！中断中必须用 taskENTER_CRITICAL_FROM_ISR

规则 ：临界区中不能做任何可能阻塞的操作 ------不能 vTaskDelay、不能等待信号量/队列，否则直接死锁。

---

三、方法2：挂起调度器（Suspending the Scheduler）

3.1 原理

如果只需要保护任务之间的互斥、不担心中断干扰，可以只暂停任务调度而不关中断：

void vTaskA(void *pvParameters) {
    for (;;) {
        vTaskSuspendAll();           /* 挂起调度器------任务不会切换 */
        sharedCounter++;             /* 中断可以打，但不会有其他任务抢 */
        xTaskResumeAll();            /* 恢复调度器 */
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

3.2 和临界区的区别

临界区 (taskENTER_CRITICAL):
  ┌──────────────┐
  │  中断 ✗      │  ← 中断也打不进来
  │  任务切换 ✗   │
  └──────────────┘

挂起调度器 (vTaskSuspendAll):
  ┌──────────────┐
  │  中断 ✔      │  ← 中断可以响应，实时性更好
  │  任务切换 ✗   │  ← 但任务不会切走
  └──────────────┘

3.3 使用场景

适合保护较长但不需要屏蔽中断的操作：

vTaskSuspendAll();
/* 批量更新多个全局变量 */
g_SystemState.voltage = adc_read(VOLTAGE_CH);
g_SystemState.current = adc_read(CURRENT_CH);
g_SystemState.temperature = sensor_read_temp();
g_SystemState.updateFlag = 1;
xTaskResumeAll();  /* 恢复调度，如有挂起的切换会在这里执行 */

注意 ：vTaskSuspendAll 也可以嵌套（内部有 uxSchedulerSuspended 计数），且挂起期间不能调用任何会导致阻塞的API。

---

四、方法3：互斥量（Mutex）------最常用的方法

4.1 互斥量的基本用法

前面的临界区和挂起调度器都比较"粗暴"，实际开发中最推荐的是互斥量：

SemaphoreHandle_t xMutex;

void vSetup(void) {
    xMutex = xSemaphoreCreateMutex();  /* 创建互斥量，初始为"可用" */
}

void vTaskA(void *pvParameters) {
    for (;;) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {  /* 拿锁 */
            sharedCounter++;           /* 临界区------安全 */
            xSemaphoreGive(xMutex);    /* 释放锁 */
        }
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void vTaskB(void *pvParameters) {
    for (;;) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
            sharedCounter--;
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

4.2 FreeRTOS互斥量的特殊能力：优先级继承

普通二值信号量没有这个能力！

场景：优先级反转问题
─────────────────────────────────────────────────────────────
  任务H (优先级3，高):  等待互斥量 ────────────────── 拿到锁，执行
  任务M (优先级2，中):                 一直跑，霸占CPU
  任务L (优先级1，低): 拿到锁 ───── 被任务M抢占 ─ 释放锁

  问题：任务M（中优先级）不让CPU给任务L，任务L不放锁，
        任务H（最高优先级）就被任务M（中等优先级）无限期阻塞！

FreeRTOS互斥量的优先级继承机制：

使用互斥量后的优先级继承：
─────────────────────────────────────────────────────────────
  任务H (优先级3):  等待互斥量 ─────────── 拿到锁执行 ─ 释放锁
  任务M (优先级2):               无法抢占！因为任务L临时变成优先级3
  任务L (优先级1): 拿锁 → 继承优先级3 ─ 执行临界区 ─ 释放锁 → 恢复优先级1

  关键：任务L持有锁期间，自动"继承"等待者的最高优先级

4.3 优先级继承的源码分析

/* 在 xSemaphoreCreateMutex() 内部 */
QueueHandle_t xQueueCreateMutex(const uint8_t ucQueueType) {
    Queue_t *pxNewQueue;
    /* ... */
    pxNewQueue->uxQueueType = queueQUEUE_TYPE_MUTEX;
    /* 互斥量特殊标记，调度器在 give/take 时能识别并执行优先级继承 */
    /* ... */
}

/* xSemaphoreTake 中------当任务阻塞等待互斥量时 */
if (pxQueue->uxQueueType == queueQUEUE_TYPE_MUTEX) {
    /* 检查是否需要优先级继承 */
    xTaskPriorityInherit(pxQueue->u.xSemaphore.xMutexHolder);
    /* 如果持有者的优先级低于当前等待任务，提升持有者的优先级 */
}

4.4 互斥量 vs 二值信号量

特性	互斥量 (Mutex)	二值信号量 (Binary Semaphore)
优先级继承	✅ 有	❌ 无
谁拿谁还？	✅ 必须（防止死锁）	❌ 可以任意任务Give
递归锁	✅ 支持（Recursive Mutex）	❌ 不支持
用作同步	不推荐	✅ 适合
用作互斥	✅ 最佳选择	不推荐

---

五、方法4：任务通知替代互斥量

当只有两个任务需要互斥访问时，任务通知是更轻量的选择：

/* 不需要创建互斥量，每个任务都有内置的通知值 */
void vTaskA(void *pvParameters) {
    for (;;) {
        /* 把任务通知当作"轻量级互斥量"------拿锁 */
        if (ulTaskNotifyTake(pdTRUE, portMAX_DELAY) > 0) {
            sharedCounter++;
            /* 释放锁------通知任务B */
            xTaskNotifyGive(oTherTaskHandle);
        }
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

对比维度	互斥量	任务通知
速度	中	快45%
RAM占用	~100字节	0（内嵌在TCB中）
多任务等待	✅	❌ 只能一个
优先级继承	✅	❌

---

六、四种方法对比总结

            保护力度：  临界区 > 挂起调度器 > 互斥量 > 任务通知
            副作用：    临界区 > 挂起调度器 > 互斥量 > 任务通知
            推荐度：    互斥量 ≈ 任务通知 > 挂起调度器 > 临界区

方法	适用场景	典型代码长度	中断安全？
临界区	极短的保护代码（<10μs），需防中断	1~3行	ISR版本独立
挂起调度器	批量更新全局变量，不需防中断	10~50行	❌
互斥量	日常开发首选，多任务互斥	5~10行	❌（ISR中不可Take）
任务通知	两个任务间的轻量级互斥	3~5行	❌

---

七、常见死锁场景与排查

7.1 经典死锁

/* 任务A：先拿 mutex1，再拿 mutex2 */
xSemaphoreTake(mutex1, portMAX_DELAY);
vTaskDelay(1);                        /* 恰好在这里切换 */
xSemaphoreTake(mutex2, portMAX_DELAY); /* 永远拿不到------任务B拿着mutex2在等mutex1 */

/* 任务B：先拿 mutex2，再拿 mutex1 */
xSemaphoreTake(mutex2, portMAX_DELAY);
xSemaphoreTake(mutex1, portMAX_DELAY); /* 永远拿不到 */

解决方案：统一加锁顺序------所有任务按相同顺序获取互斥量：

/* 规则：永远是 mutex1 → mutex2，不允许反过来 */
xSemaphoreTake(mutex1, portMAX_DELAY);
xSemaphoreTake(mutex2, portMAX_DELAY);
/* ... 操作 ... */
xSemaphoreGive(mutex2);
xSemaphoreGive(mutex1);

7.2 递归互斥量（Recursive Mutex）

同一个任务可以多次 take（需要同样次数的 give 才真正释放）：

SemaphoreHandle_t xRecursiveMutex = xSemaphoreCreateRecursiveMutex();

void vMyFunction(void) {
    xSemaphoreTakeRecursive(xRecursiveMutex, portMAX_DELAY);
    /* ... 做一些事 ... */
    vAnotherFunction();  /* 里面也会 Take 同一个互斥量------用普通互斥量会死锁 */
    xSemaphoreGiveRecursive(xRecursiveMutex);
}

---

八、面试高频考点

面试官："FreeRTOS中怎么保护共享资源？临界区和互斥量有什么区别？"

回答要点：

1. 四种方法：临界区（关中断）、挂起调度器、互斥量（含优先级继承）、任务通知
2. 临界区 vs 互斥量：临界区关中断、不可阻塞、适合极短代码；互斥量不关中断、可阻塞等待、适合较长的临界区
3. 优先级反转：是什么 → 为什么会发生 → FreeRTOS 通过互斥量的优先级继承解决
4. 互斥量 vs 二值信号量：互斥量有优先级继承、必须谁拿谁还；二值信号量无优先级继承、可用于同步

---

九、实战建议

在日常开发中，我的选择优先级是：

1. 能不共享就不共享 ------ 用消息队列传递数据副本
2. 必须共享时用互斥量 ------ 这是最安全、最清晰的方案
3. 性能敏感的两任务场景用任务通知 ------ 省RAM还快
4. 极短操作（<1μs）才用临界区 ------ 否则影响中断实时性
5. 挂起调度器用在初始化阶段 ------ 确保初始化不被切换

核心心法 ：保护粒度越细，系统实时性越好。别图省事用一个全局锁保护所有东西------这等于把RTOS退化成裸机。

---

如果这篇文章帮你理清了资源管理的思路，欢迎点赞、收藏、关注，FreeRTOS系列持续更新中！

📌 下期预告：FreeRTOS 学习笔记 18------调试方法论：HardFault 排查、栈溢出检测、运行时统计