【第23期】资源保护：关中断 vs 互斥量 (Mutex)

原创于 2025-12-28 04:14:14 发布 · 437 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#stm32 #物联网 #c语言 #开发语言 #单片机 #嵌入式硬件

嵌入式工程实战：从底层原理到架构思维专栏收录该内容

24 篇文章

订阅专栏

核心差异：关中断是“让世界停止”；互斥量是“排队等待”。而互斥量特有的 优先级继承 机制，是它区别于普通信号量的关键。

1. 裸机锁机制：关中断 (The Sledgehammer)

这是最暴力的保护方式。

// 裸机保护 I2C
__disable_irq(); // 1. 所有人闭嘴，都不许动
I2C_Write(Address, Data); // 2. 操作资源
__enable_irq(); // 3. 恢复运行

优点：速度极快，逻辑简单，绝对安全。
缺点：实时性杀手。如果你通过 I2C 发送 100 字节数据需要 5ms，那你关中断这 5ms 内，系统就像死了一样。电机控制环路会断开，高优先级中断会丢失。

在 RTOS 中，除非是极其短小的临界区（几行代码），否则严禁使用关中断来保护耗时资源。

2. RTOS 锁机制：互斥量 (Mutex)

互斥量（Mutual Exclusion）就像一把钥匙。

Take (拿钥匙)：任务 A 想用 I2C，先申请锁。如果锁没人用，拿走，进屋，锁门。
Block (排队)：任务 B 也想用 I2C，发现锁没了。RTOS 让任务 B 睡觉（阻塞），不占 CPU，直到任务 A 归还钥匙。
Give (还钥匙)：任务 A 用完了，交出钥匙。RTOS 叫醒任务 B，把钥匙给它。

// 任务 A
xSemaphoreTake(xMutexI2C, portMAX_DELAY); // 申请锁
I2C_Write(Address, Data); // 慢速操作
xSemaphoreGive(xMutexI2C); // 释放锁

这就解决了实时性问题：当任务 A 在慢慢发 I2C 时，中断依然可以响应，其他不涉及 I2C 的高优先级任务也能抢占执行。

3. 恐怖的陷阱：优先级翻转 (Priority Inversion)

既然 Mutex 这么好，为什么还需要特别设计？为什么不能用普通的二值信号量（Binary Semaphore）代替？

因为普通的排队机制会导致 “中等优先级的任务卡死高优先级任务” 的荒谬现象。

剧本推演： 有三个任务：High (高)、Medium (中)、Low (低)。只有 High 和 Low 需要共享 I2C 锁。

Low 先运行，拿到了 I2C 锁，开始干活。
High 突然醒来（比如 1ms 时间到了），抢占了 Low。
High 也要用 I2C，发现锁在 Low 手里。High 没办法，只能进入阻塞，等 Low 还有完锁。
- 此时状态：High 等 Low。这很正常。
关键时刻：突然，那个和 I2C 八竿子打不着的 Medium 醒来了！
因为 Medium 的优先级 > Low。所以 Medium 抢占了 Low，开始疯狂执行自己的业务。
灾难发生：
- High 在等 Low 还锁。
- Low 想还锁，但它被 Medium 压着不能运行。
- 结果：High 实际上在等 Medium 执行完！
- 荒谬：Medium（中）明明比 High（高）优先级低，却间接阻塞了 High。如果 Medium 是个死循环，High 就被永久饿死了。

这就是 优先级翻转。1997 年，美国的 “火星探路者号 (Mars Pathfinder)” 就因为这个问题，在火星上频繁重启，最后是工程师从地球远程修补了代码才救回来。

4. 如何破局：优先级继承 (Priority Inheritance)

为了解决这个问题，互斥量 (Mutex) 区别于 信号量 (Semaphore) 的最大特性诞生了：优先级继承。

修正后的剧本：

Low 拿到了锁。
High 醒来，申请锁，被 Low 挡住。
RTOS 介入：它可以检测到 High 被 Low 挡住了。RTOS 瞬间把 Low 的优先级提升到和 High 一样高（甚至更高一点）。
- 此时：Low 变成了 VIP。
Medium 醒来，想抢占 Low？没门！ 因为现在 Low 的优先级（临时提拔的）比 Medium 高。
Low 继续运行，直到把 I2C 用完，释放锁。
释放锁的一瞬间，Low 的优先级瞬间跌回原来的低水平。
High 拿到锁，继续运行。
High 跑完了，才轮到 Medium 跑。

总结：优先级继承机制，强迫拿着锁的低优先级任务“快点干活，干完赶紧滚”，从而避免被中等优先级的捣乱者卡住。

5. 递归锁 (Recursive Mutex)

还有一个小细节：如果同一个任务连续两次 Take 同一把锁，会怎么样？

普通 Mutex：第一次 Take 成功；第二次 Take 时，发现锁被“别人”（其实是自己）拿着，于是自己等待自己——死锁 (Deadlock)。
递归 Mutex：允许同一个任务多次 Take。它内部有个计数器，Take 几次就要 Give 几次，直到计数器归零，锁才真正释放。

适用场景：函数 A 拿了锁，调用函数 B。函数 B 为了安全，也拿同一把锁。这时必须用递归锁。

本章关键点Summary

关中断：适合极短的原子操作，不适合耗时外设。
优先级翻转：这是 RTOS 资源管理中最大的坑，中级任务可能会间接卡死高级任务。
互斥量 (Mutex)：通过 优先级继承 完美解决了翻转问题。
原则：在 RTOS 中，保护共享资源（外设、内存块），请认准 Mutex，不要用普通的 Semaphore。

/***************************************************
* 本文为作者《嵌入式开发基础与工程实践》系列文章之一。
* 关注即可订阅后续内容更新，翻阅往期信息，采用异步推送机制，无需主动轮询。
* 转发本文可视为一次网络广播，有助于更多节点接收该信息。
***************************************************/