什么是优先级反转，为什么普通 std::mutex 不行
优先级反转在嵌入式实时系统里不是理论问题，是会直接导致高优先级任务卡死的故障。典型场景：低优先级任务 A 拿着互斥锁，中优先级任务 B 抢占了 A，但高优先级任务 C 又等着锁——C 被 A 阻塞，而 A 却被 B 压着跑不起来。普通 std::mutex 完全不感知任务优先级，也不提供提升持有者优先级的机制，所以不能直接用。
POSIX 系统有 PTHREAD_PRIO_INHERIT，但嵌入式常用 RTOS（如 FreeRTOS、Zephyr）或裸机环境往往没标准 C++ 线程支持，得自己封装底层原语。
用 FreeRTOS 的 xSemaphoreCreateMutex + 优先级继承实现
FreeRTOS 的互斥信号量默认开启优先级继承，只要正确初始化并配对使用，就能解决大部分反转场景。关键不在“造轮子”，而在包装层不破坏原语语义。
- 必须用
xSemaphoreCreateMutex（不是xSemaphoreCreateBinary），后者无优先级继承 - 获取失败时不能裸调
vTaskDelay，要走xSemaphoreTake自带的阻塞逻辑，否则绕过调度器干预 - 构造函数里检查返回值是否为
NULL，FreeRTOS 内存不足时会静默失败 - 析构前必须确保锁已释放，否则
vSemaphoreDelete可能触发断言或内存泄漏
示例核心片段：
立即学习“C++免费学习笔记（深入）”；
class PriorityInheritMutex {
SemaphoreHandle_t handle_;
public:
PriorityInheritMutex() : handle_(xSemaphoreCreateMutex()) {
if (handle_ == NULL) {
// 处理创建失败，比如 panic 或返回错误码
}
}
~PriorityInheritMutex() {
if (handle_) vSemaphoreDelete(handle_);
}
bool lock(TickType_t timeout = portMAX_DELAY) {
return xSemaphoreTake(handle_, timeout) == pdTRUE;
}
bool unlock() {
return xSemaphoreGive(handle_) == pdTRUE;
}
};
裸机环境下如何模拟优先级继承
没有 RTOS 时，优先级继承只能靠“软实现”：在锁被高优先级任务争抢时，主动抬升当前持有者的执行权重。这要求你掌控所有任务调度点，且任务优先级可编程（比如 Cortex-M 的 NVIC_SetPriority）。
- 记录每个锁的当前持有者任务 ID 和原始优先级
- 每次
lock()失败前，检查是否有更高优先级任务在等待，若有则临时提升持有者优先级 - 每次
unlock()后，遍历所有等待队列，恢复被抬升任务的原始优先级 - 这个逻辑必须关中断执行，否则竞态下优先级状态会错乱
- 别试图在裸机里复刻完整的优先级天花板协议（PCP），开销太大，够用就好
Zephyr 中用 k_mutex 包装要注意的边界
Zephyr 的 k_mutex 默认启用优先级继承，但它的行为和 FreeRTOS 有细微差别，容易踩坑。
-
k_mutex_lock的超时参数是k_timeout_t类型，传K_FOREVER或K_MSEC(10)，别传裸数字 - 如果在 ISR 里误调
k_mutex_lock，会触发 kernel panic，Zephyr 明确禁止在中断上下文持互斥锁 -
k_mutex不支持递归，重复 lock 同一把锁会导致死锁，需要额外加计数字段做递归包装 - 静态初始化要用
K_MUTEX_DEFINE(my_mutex)，动态初始化后记得调k_mutex_init，漏掉会访问未初始化内存
真正难的不是写完这个包装器，而是确认整个系统里所有可能抢占路径都被覆盖——比如一个中断服务程序改了某个共享变量，而它本不该碰那把锁，这种隐式依赖最容易漏检。
