前三篇我们把 uC/OS-II 的任务管理、就绪表、调度器和时间管理啃了一遍，说实话，能一路读到这里的人，已经比大多数只会在应用层调用 API 的开发者强不少了。这一篇我们继续往内核深处走，聊一个我做项目时几乎天天用、面试时也几乎必考的主题：任务之间的同步与互斥。对应到源码，就是事件控制块（OS_EVENT）、信号量（OSSem）和互斥信号量（OSMutex）这三大块。
一个小背景：uC/OS-II 完整内核源码在典型配置下大约就是 6736 行（不同版本略有出入），这个规模在今天看来小得不可思议，但恰恰因为小，才有机会逐行读懂。前几篇我们把“CPU 下一个时刻跑谁”这件事搞清楚了，这一篇要解决的是另一个问题：“多个任务之间怎么协作、怎么抢资源、怎么不互相踩脚”。如果说调度器是内核的心脏，那事件控制块和信号量就是内核的交通警察，没有它们，任务再多也是一盘散沙。
这篇内容量不小，我会沿着 uC/OS-II 源码的实际文件顺序来讲，从数据结构设计到信号量实现，再到互斥量如何解决优先级反转，最后附上我在实际项目中踩过的坑和面试高频考点。建议你把手边的 uC/OS-II 源码打开，对照着读。
1. 先理解设计：一个事件控制块管起所有同步对象
1.1 为什么 RTOS 一定要有同步机制
先说个我实际遇到过的场景。一个采集系统里有三个任务：采集任务负责从传感器读数据，处理任务负责算特征值，上传任务负责把结果发出去。如果三个任务各跑各的，处理任务可能在采集任务还没写入新数据的时候就去读旧数据，上传任务也可能在处理任务算到一半的时候把半成品拿走。这种问题靠调度器本身是解决不了的，因为调度器只负责“哪个任务用 CPU”，不负责“业务上谁该等谁”。
uC/OS-II 给出的答案就是内核对象：信号量、互斥信号量、消息邮箱、消息队列，它们统称为“事件”（Event）。任务可以等待一个事件，也可以发布一个事件。等待的人挂起自己，发布的人唤醒别人，调度器在中间负责切换。用生活里的话说，这就好比几个人协作干活，光有排班表不够，还得有对讲机——干完的人喊一嗓子，等的人听到通知再动手。
理解这层设计意图很重要。你去看 FreeRTOS、RT-Thread、ThreadX，它们的 API 名字可能不一样，但底层思路完全相同：都有一个“等待队列 + 状态标记 + 调度触发”的机制。uC/OS-II 的特别之处在于，它把这个机制抽象得极其统一，全部塞进了一个叫做 OS_EVENT 的结构体里。
1.2 OS_EVENT 结构体逐字段拆解
打开 uC/OS-II 的 uCOS_II.H，你会看到这个核心结构体：
typedef struct os_event { INT8U OSEventType; /* 事件类型 */ void *OSEventPtr; /* 指向消息或消息队列 */ INT16U OSEventCnt; /* 信号量计数 / 互斥量信息 */ OS_PRIO OSEventGrp; /* 等待任务组（位图高位） */ OS_PRIO OSEventTbl[OS_EVENT_TBL_SIZE]; /* 等待任务表 */ } OS_EVENT;这个结构体把信号量、互斥量、邮箱、队列的“公共部分”全收进来了。OSEventType 是一个类型标记，用来区分当前这个事件到底是什么。你在 OSSemPend、OSMutexPost 这些函数里看到的第一行，一定是检查类型，比如if (pevent->OSEventType != OS_EVENT_TYPE_SEM)，类型不对直接报错返回，防止你把一个信号量当邮箱去操作。
OSEventPtr 是给邮箱和队列用的，指向实际的消息存储区。信号量用不到这个字段，但结构体里保留它，换来的是所有事件操作函数都能用同一套参数和同一套逻辑，代码量大幅下降。OSEventCnt 对信号量来说是计数值，对互斥量来说则被拆成两部分用，这部分到第三章细讲。
OSEventGrp 和 OSEventTbl 是最值得仔细看的地方。它们是“等待该事件的任务表”，用的是和就绪表一模一样的位图结构：任务优先级最高 3 位决定在 OSEventTbl 里的下标，最低 3 位决定这个字节里的哪一位。为什么要用位图而不是链表？两个原因。第一，uC/OS-II 的调度器永远选择优先级最高的任务运行，所以等待表也必须能快速找到“优先级最高的等待者”，位图配合查表法一次就能算出来，时间复杂度是 O(1)。第二，嵌入式系统内存紧张，链表的节点指针开销比位图大得多，而且链表操作的执行时间不确定，不符合 RTOS 的确定性要求。
为了加深印象，你可以对比一下就绪表：OSRdyGrp 和 OSRdyTbl[] 负责记录所有“能跑”的任务，OSEventGrp 和 OSEventTbl[] 负责记录所有“在等某个事件”的任务。前者是调度器的输入，后者是事件机制的输入，两套表结构一模一样，操作手法也一模一样。所以当你理解了怎么从就绪表里找最高优先级任务，自然就理解了怎么从等待表里找最高优先级等待者。
1.3 事件控制块的内存账本
既然结构体设计得这么统一，内存开销也要算一算。在 32 位平台（比如 Cortex-M3）上，OS_EVENT 因为指针和 INT16U 的对齐，实际占 12 字节左右。假设你在 os_cfg.h 里配置 OS_MAX_EVENTS 为 10，那么所有事件控制块一共占 120 字节。每个 OSEventTbl 数组的长度是OS_LOWEST_PRIO / 8 + 1，如果最低优先级是 63，那就是 9 字节。换句话说，整个事件机制的内存成本基本可以控制在 200 字节上下。这在动辄几 MB 内存的应用处理器上不算什么，但在只有几十 KB RAM 的单片机上，是需要精打细算的，uC/OS-II 这种位图方案在这方面非常节约。
事件控制块的分配也很有意思，它不走 malloc，而是在系统初始化时把所有 OS_EVENT 串成一个空闲链表 OSEventFreeList。创建一个信号量，本质上就是从链表头部摘一个节点下来；删除信号量，就是把节点放回链表头部。这种做法没有内存碎片，执行时间完全确定，对 RTOS 来说非常重要。后面看 OSSemCreate 源码时，你会看到这个过程的完整实现。
2. 信号量源码精读：OSSemCreate / Pend / Post
2.1 OSSemCreate：事件对象从哪里来
信号量是 uC/OS-II 里最简单、最常用的同步对象。先看创建函数：
OS_EVENT *OSSemCreate (INT16U cnt) { OS_EVENT *pevent; if (OSIntNesting > 0) { /* 中断里不允许创建 */ return ((OS_EVENT *)0); } OS_ENTER_CRITICAL(); pevent = OSEventFreeList; /* 从空闲链表取头节点 */ if (OSEventFreeList != (OS_EVENT *)0) { OSEventFreeList = (OS_EVENT *)OSEventFreeList->OSEventPtr; } OS_EXIT_CRITICAL(); if (pevent != (OS_EVENT *)0) { pevent->OSEventType = OS_EVENT_TYPE_SEM; pevent->OSEventCnt = cnt; pevent->OSEventPtr = (void *)0; OS_EventWaitListInit(pevent); /* 清空等待表 */ } return (pevent); }第一件需要注意的事：OSIntNesting > 0时直接返回 NULL。这个判断体现了 RTOS 的一个铁律——中断上下文里不能调用可能阻塞或需要调度器的服务。创建信号量虽然本身不会阻塞，但它要操作内核数据结构，而中断里可能存在更紧急的事，所以干脆不允许，这也是很多 RTOS 的常见约束。
OS_ENTER_CRITICAL 和 OS_EXIT_CRITICAL 是进入/退出临界区的宏，在大多数移植里就是关中断和开中断。为什么取一个空闲节点要关中断？因为 OSEventFreeList 是全局变量，如果任务 A 正在摘节点时被中断打断，而中断服务程序里恰好也创建了一个事件，链表就可能被弄坏。这是最典型的“共享资源保护”场景。
创建完成后，OSEventCnt 被设置为初始计数。信号量的计数值代表“当前可用的资源数量”。这个值是有上限的，因为 OSEventCnt 是 16 位无符号整数，最大 65535，后面 OSSemPost 里你也会看到溢出保护。
2.2 OSSemPend：拿不到资源就果断挂起自己
Pend 是“等待”的意思，这是信号量操作里最核心、也最容易读晕的函数。完整源码如下：
void OSSemPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { OS_ENTER_CRITICAL(); if (pevent->OSEventType != OS_EVENT_TYPE_SEM) { OS_EXIT_CRITICAL(); *perr = OS_ERR_EVENT_TYPE; return; } if (pevent->OSEventCnt > 0) { /* 资源可用 */ pevent->OSEventCnt--; OS_EXIT_CRITICAL(); *perr = OS_ERR_NONE; return; } /* 资源不可用，任务进入等待 */ OSTCBCur->OSTCBStat |= OS_STAT_SEM; OSTCBCur->OSTCBPendTO = FALSE; OSTCBCur->OSTCBDly = timeout; OS_EventTaskWait(pevent); /* 加入等待表，移出就绪表 */ OS_EXIT_CRITICAL(); OSSched(); /* 让出 CPU，调度其他任务 */ OS_ENTER_CRITICAL(); if (OSTCBCur->OSTCBPendTO == TRUE) { /* 超时唤醒 */ OS_EventTO(pevent); OS_EXIT_CRITICAL(); *perr = OS_ERR_TIMEOUT; return; } OSTCBCur->OSTCBEventPtr = (OS_EVENT *)0; OS_EXIT_CRITICAL(); *perr = OS_ERR_NONE; }这段代码的逻辑可以拆成三块。第一块是类型检查，第二块是“有货就拿走”的快速路径，第三块是“没货就挂起”的慢速路径。
快速路径很好理解：如果计数值大于 0，说明资源可得，先减 1，然后返回。注意这个减 1 是“占有”的意思，不是“消耗”。信号量代表的资源被当前任务拿走了，别人要再拿就得等。
慢速路径才是关键。资源不够时，当前任务不能继续往下跑，它要做三件事：把自己标记为“正在等信号量”（OSTCBStat |= OS_STAT_SEM）、记录超时时间（OSTCBDly = timeout）、把自己从就绪表挪到等待表。最后这个动作由 OS_EventTaskWait 完成：
void OS_EventTaskWait (OS_EVENT *pevent) { OSTCBCur->OSTCBEventPtr = pevent; /* 记住自己在等谁 */ pevent->OSEventTbl[OSTCBCur->OSTCBPrio >> 3] |= 1 << (OSTCBCur->OSTCBPrio & 7); pevent->OSEventGrp |= OSTCBCur->OSTCBPrio; /* 加入等待表 */ OSRdyTbl[OSTCBCur->OSTCBPrio >> 3] &= ~(1 << (OSTCBCur->OSTCBPrio & 7)); if (OSRdyTbl[OSTCBCur->OSTCBPrio >> 3] == 0) { OSRdyGrp &= ~OSTCBCur->OSTCBPrio; /* 从就绪表移除 */ } }OSTCBCur是当前任务的 TCB 指针。OSEventTbl[prio >> 3]负责定位这个任务优先级对应的位，OSEventGrp记录高 3 位，这两行操作就把当前任务挂到了对应事件的等待表里。紧接着的三行，是把当前任务在就绪表里的位清掉。一个任务挂起，本质就是“从就绪表删除 + 加入某个等待表”，就这么简单。
挂起之后，代码退出临界区，然后调用 OSSched() 让出 CPU。这里有一个非常值得注意的细节：为什么不在临界区里直接调度？因为 OSSched 内部有自己的临界区保护，如果一个已经关中断的代码路径里再触发任务切换，中断关闭时间会被不必要地拉长，在部分 CPU 移植上还可能造成嵌套临界区的问题。所以 uC/OS-II 的惯例是：在临界区里修改好状态，退出临界区后再调度。
当其他任务调用 OSSemPost 把这个信号量释放，或者超时时间到了，当前任务会被重新放回就绪表，获得运行机会。这时它从 OSSched() 调用后面继续执行，第一件事就是检查OSTCBCur->OSTCBPendTO。这个标志在挂起时被清成 FALSE，如果任务是被 Post 正常唤醒的，它就保持 FALSE；如果是超时唤醒的，OSTimeTick 会把它置成 TRUE。所以这个标志就是任务用来区分“我等到资源了”还是“我超时了”的唯一依据。如果是超时，还要调用 OS_EventTO 把自己从等待表里清掉，避免残留脏数据。
2.3 OSSemPost：先唤醒等待者，再考虑计数值
Post 是“发布”的意思，对应放回资源。源码如下：
INT8U OSSemPost (OS_EVENT *pevent) { OS_ENTER_CRITICAL(); if (pevent->OSEventType != OS_EVENT_TYPE_SEM) { OS_EXIT_CRITICAL(); return (OS_ERR_EVENT_TYPE); } if (pevent->OSEventGrp != 0) { /* 有任务在等 */ OS_EventTaskRdy(pevent, (void *)0, OS_STAT_SEM); OS_EXIT_CRITICAL(); OSSched(); /* 让被唤醒的任务有机会立即运行 */ return (OS_ERR_NONE); } if (pevent->OSEventCnt < 65535u) { /* 无等待者，计数加 1 */ pevent->OSEventCnt++; OS_EXIT_CRITICAL(); return (OS_ERR_NONE); } OS_EXIT_CRITICAL(); return (OS_ERR_SEM_OVF); /* 溢出 */ }Post 的核心逻辑是“先看有没有人等，有人等就优先唤醒人，没人等才增加计数”。这里的顺序非常重要。想象一个二值信号量，初始值是 0，任务 A 在 Pend 它，任务 B 在 Post 它。如果 Post 先把计数加 1 再去唤醒 A，那么计数变成 1，A 被唤醒后执行 Pend，又把计数减成 0，这一来一回虽然结果一样，但中间多了一次无意义的计数变动。更重要的是，如果 Post 先加 1 而不唤醒任务，A 就不知道自己可以运行了，必须依赖其他时机被调度，实时性就差。所以 uC/OS-II 的做法是：有等待任务就直接从等待表里挑一个最高优先级的任务放回就绪表，计数值不动，相当于“直接把资源交给等待者”。
OS_EventTaskRdy 是唤醒的核心函数，它用两次查表法快速找到最高优先级的等待任务：
INT8U OS_EventTaskRdy (OS_EVENT *pevent, void *pmsg, INT8U msk) { INT8U prio; INT8U x; INT8U y; OS_TCB *ptcb; y = OSUnMapTbl[pevent->OSEventGrp]; /* 查表：最高优先级的高3位 */ x = OSUnMapTbl[pevent->OSEventTbl[y]]; /* 查表：最高优先级的低3位 */ prio = (INT8U)((y << 3) + x); /* 合成完整优先级 */ ptcb = OSTCBTbl[prio]; ptcb->OSTCBDly = 0; ptcb->OSTCBEventPtr = (OS_EVENT *)0; ptcb->OSTCBStat &= ~msk; /* 清掉等待标志 */ if (ptcb->OSTCBStat == OS_STAT_RDY) { /* 没有其他事件在等 */ OSRdyGrp |= ptcb->OSTCBPrio; OSRdyTbl[ptcb->OSTCBPrio >> 3] |= 1 << (ptcb->OSTCBPrio & 7); } pevent->OSEventTbl[y] &= ~(1 << x); /* 从等待表移除 */ if (pevent->OSEventTbl[y] == 0) { pevent->OSEventGrp &= ~ptcb->OSTCBPrio; } return (prio); }这段代码里的 OSUnMapTbl 是一张 256 字节的查找表，输入一个字节，输出这个字节中最低置 1 位的位置。比如输入 0x08（二进制 00001000），输出 3。这个查表法同样用于就绪表寻找最高优先级任务，是 uC/OS-II 最经典的优化手法之一。注意 H2 章节开头我说过“等一个事件的任务里，优先级数字最小的应该最先被唤醒”，OS_EventTaskRdy 做的就是这件事，而且一次查表就从 256 种可能里定位到了答案。
Post 之后还有一个动作：如果不在中断里，会调用 OSSched() 主动让出 CPU。因为刚刚唤醒了一个更高优先级的任务，如果当前任务不主动让出，那个被唤醒的任务就得等到下一次时钟节拍或别的调度点才有机会运行，实时性就打了折扣。如果 OSSemPost 是在中断服务程序里调用的，OSSched() 不会真正切换（因为 OSIntNesting > 0），调度会被推迟到中断退出时由 OSIntExit 统一处理。这是 uC/OS-II 的一个设计惯例：中断级调度一律推到中断尾声。
2.4 实战演练：用信号量实现生产者-消费者模型
光看源码不落地不行，我给你一个我在测试板上跑过的迷你例程，能非常直观地观察信号量计数变化。
#define BUF_SIZE 8 OS_EVENT *SemEmpty; /* 缓冲区空位数，初始 8 */ OS_EVENT *SemFull; /* 缓冲区数据数，初始 0 */ INT8U Buf[BUF_SIZE]; INT8U InIdx = 0, OutIdx = 0; void ProducerTask (void *pdata) { INT8U data = 0; for (;;) { data++; OSSemPend(SemEmpty, 0, &err); /* 有空位才放 */ Buf[InIdx] = data; InIdx = (InIdx + 1) % BUF_SIZE; OSSemPost(SemFull); /* 通知消费者 */ OSTimeDly(10); } } void ConsumerTask (void *pdata) { INT8U data; for (;;) { OSSemPend(SemFull, 0, &err); /* 有数据才取 */ data = Buf[OutIdx]; OutIdx = (OutIdx + 1) % BUF_SIZE; OSSemPost(SemEmpty); /* 释放一个空位 */ /* 处理 data */ } }初始状态 SemEmpty = 8，SemFull = 0。生产者每放一个数据，SemEmpty 减 1，SemFull 加 1；消费者每取一个数据，反过来。当缓冲区满时，SemEmpty 变成 0，生产者再 Pend 就会挂起进入等待表，直到消费者取走数据并 Post(SemEmpty)。你可以在调试器里观察 SemEmpty 和 SemFull 的计数变化，确认它永远不会出现负数，也不会超过 8。
我自己第一次跑这个例程时，习惯性地在 Pend 之前加了一个断言检查返回值，结果发现超时参数填 0 表示“永远等”，一旦逻辑写错，任务就永远挂在那里了，板子表现为“卡死”。后来养成了一个习惯：所有 Pend 都填一个明确的超时时间，返回值也认真判断，这在实际项目中能省下大量排查时间。
3. 互斥信号量：专门用来治优先级反转
3.1 什么是优先级反转，一个必须掌握的经典问题
普通信号量能解决同步问题，但解决不了“互斥访问”场景下的一个经典问题——优先级反转。假设系统里有三个任务：任务 A 优先级最高，任务 B 优先级中等，任务 C 优先级最低。任务 C 先拿到了一把锁，正在访问共享资源。这时任务 A 就绪了，它也想拿这把锁，发现锁被 C 占着，于是 A 挂起等待。到这里都还正常，问题是：如果任务 B 恰好也在这时就绪了，因为 B 的优先级比 C 高，所以调度器会立刻让 B 抢走 CPU。B 跑完之前，C 根本没有机会运行，也就无法释放锁，于是最高优先级的 A 被中优先级的 B 活活“憋死”。
下面的表格把这个过程看得更清楚：
| 时间 | 就绪状态 | 当前运行 | 说明 |
|---|---|---|---|
| t1 | C 运行，持锁 | C | C 获取锁 |
| t2 | A 就绪，等待锁 | C | C 继续跑（A 还没来或优先级策略决定） |
| t3 | A 等待锁，B 就绪 | B | B 抢占 C，A 被间接阻塞 |
| t4 | A 等待锁，B 运行中 | B | 高优先级 A 被中优先级 B 拖住 |
| t5 | B 完成，C 继续 | C | C 终于释放锁 |
| t6 | A 获取锁 | A | 反转结束，但已浪费大量时间 |
这个问题的可怕之处在于：从现象上看，A 是因为 C 才无法运行，但真正让 A 迟迟无法运行的是 B。普通信号量完全没有能力阻止 B 抢在 C 前面执行，因为内核不知道 C 持有锁、也不知道 A 在等锁。
3.2 优先级继承在 uC/OS-II 中的落地：OSMutex
uC/OS-II 的处理方案叫优先级继承（Priority Inheritance）。思路很直接：当高优先级任务 A 因为等待一把锁而被阻塞时，内核把持有锁的低优先级任务 C 的优先级临时提升到 A 的优先级。这样一来，C 就有资格跟 B 抢 CPU 了，C 能尽快运行、尽快释放锁，A 也就能尽快被唤醒。
为了支持这个机制，互斥信号量复用了 OSEventCnt 这个 16 位字段，但用法和普通信号量完全不同。高 8 位用来保存“占用互斥锁的任务的优先级”，低 8 位用来表示锁的状态，加锁时低 8 位为 0xFF，未加锁时低 8 位为 0。你可以把它理解成一个复合结构：高 8 位是“谁的锁”，低 8 位是“锁的状态”。
OSMutexPend 的简化逻辑是这样的：
void OSMutexPend (OS_EVENT *pevent, INT16U timeout, INT8U *perr) { OS_ENTER_CRITICAL(); if ((INT8U)(pevent->OSEventCnt & 0xFF00) == 0) { /* 锁未被占用 */ pevent->OSEventCnt &= 0x00FF; /* 清空高8位 */ pevent->OSEventCnt |= (INT16U)(OSTCBCur->OSTCBPrio << 8); /* 记录占用者 */ pevent->OSEventCnt |= 0x00FF; /* 置为锁定 */ OS_EXIT_CRITICAL(); *perr = OS_ERR_NONE; return; } if ((INT8U)(pevent->OSEventCnt >> 8) == OSTCBCur->OSTCBPrio) { OS_EXIT_CRITICAL(); *perr = OS_ERR_MUTEX_DEADLOCK; /* 自己抢自己的锁 */ return; } if ((INT8U)(pevent->OSEventCnt >> 8) < OSTCBCur->OSTCBPrio) { /* 持有者优先级低于当前任务，临时提升持有者 */ ptcb = OSTCBTbl[pevent->OSEventCnt >> 8]; ptcb->OSTCBPrio = OSTCBCur->OSTCBPrio; /* 提升 */ /* 更新就绪表，让持有者能以更高优先级运行 */ } /* 当前任务挂起，等待锁 */ OSTCBCur->OSTCBStat |= OS_STAT_MUTEX; OS_EventTaskWait(pevent); OS_EXIT_CRITICAL(); OSSched(); }注意这里有两个容易忽略的细节。第一个是死锁检测：如果当前任务已经持有这把锁，又来了一次 Pend，说明“自己等自己”，这必然是逻辑错误，直接返回错误码，避免系统陷入死锁。第二个是优先级比较的方向：这个判断用的是<而不是>，因为 uC/OS-II 里数字越小优先级越高。持有者优先级数值比当前任务大，说明持有者优先级低，才有提升的必要。
OSMutexPost 则是逆操作：如果锁已经被占、现在要释放，先把持有者的优先级恢复到原始值（如果之前被提升过），再把锁置为未加锁状态。如果有任务在等待，则直接把锁的所有权移交给等待任务中优先级最高的那个，同时把它的优先级作为新的高 8 位信息。这比普通信号量多了一次“优先级恢复”的动作，所以互斥量的开销会比信号量稍微大一点，但换来的是实时性的安全。
我在实际项目中的体会是：共享资源优先用互斥信号量，而不是普通信号量，这一点从设计规范上就要定死。普通信号量适合表达“有多少资源可用”的计数语义，比如缓冲区的空位数、数据包个数；互斥信号量只回答“这把锁现在是谁的”。把两者搞混，是最容易埋雷的地方。
3.3 优先级继承不是银弹：它的边界和替代方案
优先级继承能解决单层反转问题，但并不能解决所有情况。最典型的就是“继承链”：低优先级任务持有锁 A，同时它又在等另一把锁 B，而锁 B 被一个优先级更低的任务占着。这种情况下，优先级继承会沿着锁的依赖链一级级传导，形成一条很长的临时优先级链，任何一环处理不当，实时性照样崩。
所以工程上的经验是三管齐下：第一，互斥锁的持有时间要尽量短，临界区里只做最必要的操作，不要做计算密集任务。第二，尽量避免锁的嵌套，如果实在躲不开，团队里约定所有任务按同一顺序获取锁，这一步能消除大多数死锁。第三，实在对实时性要求极端的场景，可以考虑无锁设计，比如用环形缓冲区加原子变量，或者让每个任务独占资源。
补充一个对比知识点，面试也经常问：优先级继承和优先级天花板（Priority Ceiling）的区别。优先级继承是“动态”的，只有发生等待时才临时提升，提升幅度跟等待任务的优先级有关；优先级天花板是“静态”的，一把锁在创建时就定好了一个最高优先级，任何任务拿锁时都被提升到这个固定值。前者灵活但复杂，后者简单但可能过度提升。uC/OS-II 用的是前者，RT-Thread 的互斥量也是前者，Cortex-M 内置的互斥机制更接近后者。
4. 常见问题、排查经验与源码阅读方法
4.1 踩坑记录一：中断服务程序里调用 Pend，系统直接崩
这个问题我在刚用 uC/OS-II 时踩过。当时想在定时器中断里等待一个信号量，心想“反正信号量很快就会有”，结果板子直接跑飞。原因其实在 OSSemPend 源码里写得很清楚：Pend 在资源不可用时会调用 OS_EventTaskWait 把当前任务从就绪表移除，但中断里根本没有“当前任务”的概念，OSTCBCur 指向的是被打断的任务，它的上下文不能在中断里随意修改。而且后面调用的 OSSched 在 OSIntNesting > 0 时不会真正切换，任务状态却已经被改了，整个系统的任务状态就乱套了。
正确做法是：中断里只调用 Post 或直接给任务发消息，Pend 永远放在任务上下文里。这个规则不只适用于 uC/OS-II，几乎所有 RTOS 都遵守，可以说是一条铁律。
4.2 踩坑记录二：信号量泄漏和二值信号量用错场景
所谓信号量泄漏，是指 Post 的调用次数长期多于 Pend，导致计数值一直往上累加。表面上系统没崩溃，但语义已经错了，本应“只有一个资源”的信号量变成了“有无穷多个资源”。比如你用二值信号量保护一个临时变量，任务 A 在 Post 时没加锁保护共享数据，中断里又重复 Post，结果计数变成 2，另一个任务也能进来了，数据就被踩坏。
排查这类问题没有捷径，最好是在调试器里监视 OSEventCnt 的变化，配合断点查看每次 Post 的调用栈。经验是：计数信号量该用OS_EVENT_TYPE_SEM，互斥锁该用OS_EVENT_TYPE_MUTEX，两者不要混用。互斥信号量本身设计为二值，不允许多次加锁。如果你需要一个可重入的锁，就得自己设计嵌套计数机制，uC/OS-II 本身不提供。
4.3 踩坑记录三：超时参数填 0，死锁时连救场的机会都没有
OSSemPend 的第二个参数是超时时间，填 0 表示永久等待。很多初学者图省事，一律填 0。这在单任务逻辑里没问题，但一旦多任务之间存在资源依赖，就可能出现死锁：任务 A 持有锁 1 等锁 2，任务 B 持有锁 2 等锁 1，两个任务都在永久等待，整个系统卡死。
我的建议是：所有 Pend 都填一个超时值，哪怕填几百个时钟节拍。这样就算逻辑出问题，任务也会定时醒来报错，不至于把整个系统拖死。配合 uC/OS-II 的错误返回码，你可以把OS_ERR_TIMEOUT当成一个排查信号，在调试日志里打印出来。这个习惯救过我至少两次项目事故。
4.4 从 6736 行代码里提炼出的读码路线图
很多人拿到源码不知道怎么读，我提供一个实际的路径，按这个顺序读下来会顺畅很多：
| 阶段 | 文件/模块 | 核心问题 |
|---|---|---|
| 1 | OS_CORE.C | 系统初始化、OSSched、OSIntExit |
| 2 | OS_TASK.C | 任务创建、删除、挂起、恢复 |
| 3 | OS_TIME.C | OSTimeTick、延时、超时机制 |
| 4 | OS_SEM.C / OS_MUTEX.C | 本篇内容，同步与互斥 |
| 5 | OS_MBOX.C / OS_Q.C | 消息邮箱、消息队列 |
| 6 | OS_MEM.C | 固定大小内存块管理 |
| 7 | 移植层 os_cpu_a.asm | 任务切换的汇编实现 |
前三个阶段你理解了“谁在跑、怎么切、怎么算时间”，第四阶段就是我们这篇正在做的事。读完同步互斥后，邮箱和队列其实就是“带消息指针 + 等待表”的变体，OSEventPtr 字段会在那里派上用场。你会发现很多函数结构惊人地相似，因为 uC/OS-II 的事件机制统一下来，后面全是套模板。
读的过程中我强烈建议你手里拿一张纸，把任务状态转换画出来。比如一个任务从就绪表删掉、加入等待表、被唤醒、重新加入就绪表，每一步涉及哪些字段变化，写下来对照代码走一遍。这个方法听着土，但对建立操作系统心智模型特别有效。
4.5 RTOS 面试高频题速查
| 问题 | 回答要点 |
|---|---|
| 信号量 Pend 时计数值什么时候减？ | 有可用资源时先减再返回；资源不可用时减 0，任务挂起 |
| 信号量 Post 时计数值什么时候加？ | 有等待者时直接唤醒最高优先级的等待者，计数不变；无等待者时才加 |
| 为什么等待表用位图不用链表？ | 位图查表 O(1) 且执行时间确定，内存开销小 |
| 优先级反转是什么？怎么解决？ | 高优先级任务被低优先级任务间接阻塞；解决用优先级继承或优先级天花板 |
| uC/OS-II 的互斥量和信号量区别？ | 互斥量支持优先级继承，有死锁检测，语义是互斥；信号量是计数 |
| 中断里能调用 Pend 吗？ | 不能，只能 Post，调度会被推迟到中断退出时处理 |
| 就绪表和等待表有什么联系？ | 结构一样，都用 OSRdyGrp / OSEventGrp 加对应 Tbl 表示位图，一个管能跑的任务，一个管等待的任务 |
这些问题我在面试别人时也喜欢问，能答到第三题以后的人，基本可以确定是真读过源码的。
读 uC/OS-II 最让我感慨的是，6736 行代码里没有一个多余的组件。信号量、互斥量、邮箱、队列，共享同一个事件控制块结构，共享同一套等待表操作，甚至连查表法都是从就绪表那边直接复用过来的。这种“一套机制，多处复用”的设计哲学，比任何优化技巧都值得学习。很多人在学会用 API 之后就觉得自己懂 RTOS 了，但你真正把 Pend 和 Post 的源码读一遍，才会理解为什么信号量能在任务和中断之间安全传递，为什么互斥量能解决优先级反转，为什么 RTOS 内核必须是“关中断、改表、开中断、再调度”这个节奏。
下一篇我们聊聊消息邮箱和消息队列，看看 uC/OS-II 是怎么把“数据传递”也塞进同一个事件框架里的。如果这篇对你有帮助，建议你打开源码对照再走一遍，尤其是 OS_EventTaskWait 和 OS_EventTaskRdy 这两个函数，自己画一遍位图的变化，收获会非常大。
