锁的抽象层与陷阱

一、盘点：五套锁并存是什么样子 打开一个运行了几年、融合了自研代码 + 开源框架 + 第三方库的嵌入式工程，锁通常是这样的： 族代表 API谁产生的能否在中断里用与其他族是否互通内核互斥量mutex_take / mutex_releaseRTOS 原生否（会睡眠）否内核信号量/事件sem_take / sem_release、event_sendRTOS 原生仅 release/send否POS

锁的优先级反转

锁系列第二篇。互斥锁解决"互斥"，但不解决"公平"。本篇从一次真实的航天事故讲起，把优先级反转完整推演一遍，然后对比三种解法、讲清等待队列策略的配套关系，最后给出可落地的排查与防御手段。文中代码为伪代码，事故细节引自公开资料。 一、开场：火星上的反复重启 1997 年，火星探路者号着陆器在火星表面执行任务期间，出现了周期性复位。地面收到的遥测显示： 系统反

从大锁到分片锁

一、引子：一次点击到上屏，卡在哪了 现象很典型： 界面响应"能感觉到慢"，但 CPU 占用只有 20%掉帧是偶发的，压测时复现不了单看每个函数的耗时都正常，没有任何一个函数"很慢" 这类问题最容易把人带进死胡同：你去优化那个"最慢的函数"，改了半天，现象不变。 换个问法就有出口：不是"谁慢"，而是"谁在等谁