尧图网页设计 
这个手搓RTOS的系列写到第8篇。前面几篇我们把任务切换、延时、调度器都跑通了LED灯也能按照任务函数里的延时各自闪起来。但真到了这一步你会发现一个很尴尬的事实两个任务只要开始“配合干活”光靠延时函数根本写不出正确的逻辑。你要么看到串口日志乱成一团要么发现一个任务总是抢先一步导致整个状态错乱。信号量就是专门来解决这些问题的它是RTOS里任务同步与资源共享的基石也是我们从“点灯大师”往真正操作系统开发者迈进的关键一环。这篇文章我会从零开始围绕信号量的内核模型、take/give核心实现、任务同步实测、资源共享实测、中断安全设计、优先级反转这几个方向把信号量的方方面面拆开讲透。适合正在跟我一样手写RTOS的朋友也适合已经用过FreeRTOS等现成系统但想搞清楚信号量底层原理的开发者。就算你完全没接触过操作系统只要会C语言和一点链表操作也能跟着把信号量写出来跑起来。1. 点灯难度升级前先想清楚一个问题任务之间到底在抢什么1.1 第一阶段你的第一个多任务点灯程序其实什么都没抢很多人的RTOS入门第一课都是点灯。比如创建两个任务task_led1每300ms翻转一次LED1task_led2每500ms翻转一次LED2系统跑起来之后两个灯各闪各的看着很热闹。这时候你会觉得用RTOS也不过如此不就是把while循环拆成几个函数嘛用裸机延时也差不多能做。但这里有个容易忽略的事实这两个任务能互不干扰地运行是因为它们之间根本没有共享任何数据。LED1的GPIO寄存器地址虽然在底层只有一个但你在两个任务里翻转的是不同的PIN位底层硬件也不存在“同时写一个位”的竞争窗口所以裸机也能跑多个任务也能跑。也就是说你还没遇到RTOS真正要解决的问题。1.2 第二阶段从“各亮各的”变成“一起干活”就出事了一旦任务之间需要共享数据或协调时序问题立刻冒出来。举个最常见的例子两个任务都要通过同一个UART打印调试信息。task_a每秒打印一行温度task_b每2秒打印一行湿度单独看逻辑没问题但跑起来你会看到这样的输出temp25 hum60 temp26 hum61 temp27偶尔还会出现一行输出被切断的情况比如hum6后面直接跟了temp2整行日志彻底错乱。原因很简单printf内部是分多次往UART发送寄存器写数据的task_a刚写到一半时间片到了task_b抢占了CPU也往同一个UART寄存器写数据两个任务的字符就交织在一起了。再举一个更隐蔽的例子两个任务共同维护一个全局变量g_counter一个做g_counter另一个做g_counter--。在C语言里g_counter不是一条机器指令在Cortex-M3上它至少是“读内存-加一-写内存”三步。如果task_a读完旧值还没写回task_b已经完成了它的修改最后写回的那个任务会把对方的修改覆盖掉这个变量就丢了更新而且问题极难复现。这种问题有个专门的名字叫竞态条件Race Condition。1.3 我总结下来的三类经典症状问题类型表面现象根因互斥失败竞态串口日志乱码、共享计数不对、数据被覆盖多个任务同时进入了临界资源区同步丢失任务B在任务A发出数据之前就启动拿到的是旧状态任务之间有先后依赖但没有任何机制强制顺序死锁任务假装不运行了系统整体卡死看门狗乱叫任务等了一个永远等不到的信号量或者锁的获取顺序写反这三个问题信号量都能治只是用法不一样互斥问题用“二值信号量当作锁”来治同步问题用“二值信号量当作事件通知”来治生产消费问题用“计数信号量”来治。后面每个场景我都会给实测代码。2. 信号量的内核模型一个计数值加一条等待队列2.1 用餐厅叫号系统理解信号量信号量这个名字起得挺玄乎但它的内核模型特别简单就两个东西一个count计数器和一条等待队列。我习惯用餐厅叫号来类比。餐厅门口有个取号机当前号码是8号这就相当于count 1还有1个“可用资源”即8号还没被叫到。取号这个动作就是take如果还有可用号码拿一个走count减一如果没有可用号码了你就得在等待区排队这就对应把当前任务挂到信号量的等待队列上。叫号这个动作就是give服务员喊“8号请用餐”如果有人在等待就先让队首的人进去count不变如果没人等号码池里的可用号码就会增加count加一。把这个模型落到代码上信号量的“资源”不一定是某种实物它可以是“一把锁的占用权”也可以是“某个事件是否发生”的标记。这也是为什么信号量既能做互斥又能做同步因为它本质上就是一种“资源数量等待者队列”的通用的内核对象。2.2 二值信号量与计数信号量的本质区别信号量按最大计数值分为二值信号量Binary Semaphore和计数信号量Counting Semaphore。这个区别必须在设计数据结构的时候就留好字段后面实现才有依据。维度二值信号量计数信号量最大计数值1NN大于1初始值常见设置1表示锁空闲0表示事件未发生N表示N个可用资源典型用途互斥锁、任务间事件通知资源池管理、生产者-消费者模型实现注意give时count不能超过1否则锁会失效count可以累加到N注意别溢出很多初学者觉得二值信号量就是count最大为1的计数信号量这个理解本身没错但你要注意一个坑二值信号量被用做互斥锁时如果写give的代码没有加“最大为1”的限制一旦某个bug导致连续give了两次count会变成2此时两个任务同时都能拿到锁互斥保护直接失效。这个我在后面代码实现里会重点处理。2.3 我设计的miniOS信号量结构体我在自己的miniOS里把信号量定义成这样的结构体#define SEM_TYPE_BINARY 0 #define SEM_TYPE_COUNT 1 typedef struct mini_sem { uint8_t type; /* 二值还是计数 */ uint32_t count; /* 当前可用资源数 */ list_t wait_list; /* 等待该信号量的任务队列 */ } mini_sem_t;每个字段的作用都很直白。type决定give时要不要把count限制在1count是信号量最核心的状态初值由用户设置wait_list是一个双向链表链表的每一个节点对应一个因为拿不到信号量而陷入阻塞态的任务控制块。这里有个设计细节值得提一下任务控制块TCB里要么持有链表节点要么直接作为链表节点被串起来。我采取的是TCB内嵌list_node的方式也就是说等待队列存的是TCB节点本身这样从队列上摘下一个节点时就能直接拿到那个任务的所有信息不用再做一次“节点地址到任务地址”的反查。初始化函数也很简单void mini_sem_init(mini_sem_t *sem, uint8_t type, uint32_t init_count) { sem-type type; sem-count init_count; list_init(sem-wait_list); }初始化信号量的时机一定要在任何一个任务使用它之前否则会出现某个任务已经在等待了但wait_list还没有初始化的未定义行为。在RTOS的世界里“先初始化再用”是铁律。3. 手写核心原语take和give的完整实现3.1 为什么必须先关中断信号量的take和give看起来只有几行逻辑但它们不是普通函数它们操作的数据结构可能被多个任务同时访问。比如task_a正要执行count--指令还没执行完SysTick中断触发了调度器把task_b切换进来了task_b也执行到count--这时候count的修改就乱了。要保证“检查count-修改count-决定是否挂起”这个过程不被打断最简单的办法就是关中断。在Cortex-M3上可以通过设置PRIMASK寄存器来屏蔽所有可屏蔽中断实现一个原子临界区。临界区里面做的事情越少越好只做必要的队列操作和状态修改绝对不要把printf、复杂运算这种耗时操作放进去。我在miniOS里封装了两个宏#define arch_enter_critical() arch_disable_irq() /* 关中断 */ #define arch_exit_critical() arch_enable_irq() /* 开中断 */在实际项目里enter返回当前的PRIMASK状态exit时恢复而不是无条件打开这样可以支持临界区嵌套调用。这里的嵌套场景以后写互斥量、调试打印的时候会碰到建议一次做对。3.2 take的核心实现uint32_t mini_sem_take(mini_sem_t *sem, uint32_t timeout) { uint32_t saved; task_t *cur; saved arch_enter_critical(); /* 还有可用资源直接拿到 */ if (sem-count 0) { sem-count--; arch_exit_critical(saved); return 0; /* 返回0表示获取成功 */ } /* 没有资源并且不打算等立即失败返回 */ if (timeout 0) { arch_exit_critical(saved); return 1; /* 返回非0表示获取失败 */ } /* 把自己挂到等待队列上等别人give */ cur current_task; cur-state TASK_STATE_BLOCKED; cur-wait_sem sem; cur-take_result 1; /* 先默认失败被唤醒后give会改成0 */ list_add_tail(sem-wait_list, cur-list_node); arch_exit_critical(saved); /* 主动让出CPU切换去执行其他任务 */ schedule(); /* 被唤醒后回到这里返回结果 */ return cur-take_result; }这段代码有几个关键点。第一count 0和count--必须在同一个临界区内完成否则两个任务可能同时看到count等于1然后各自减一最后两个任务都觉得自己拿到资源了。第二当count为0且timeout不为0时任务不能一直占着CPU空转它必须主动调用schedule()让出处理器。这就是RTOS里“阻塞态”的由来任务把自己放到等待队列上然后不再参与调度直到有人唤醒它。第三我在挂起前先把cur-take_result置为1意思是“如果没人来叫我我就一直等直到give把我唤醒并告诉我成功为止”。为什么不在pending之后设置为0因为give可能会在另一个任务上下文里修改这个任务控制块的字段所以唤醒逻辑里会负责把take_result改成0这样当前任务被切换回来之后直接读这个字段就行。3.3 give的核心实现uint32_t mini_sem_give(mini_sem_t *sem) { uint32_t saved; task_t *task; uint32_t need_sched 0; saved arch_enter_critical(); /* 有任务在等待直接把资源转交给队首任务 */ task list_first(sem-wait_list); if (task) { list_remove(task-list_node); task-state TASK_STATE_READY; task-take_result 0; /* 告诉它拿到了 */ add_to_ready_list(task); if (task-prio current_task-prio) { need_sched 1; /* 被唤醒的任务优先级更高需要切换 */ } } else { /* 没有任务等待资源归还给信号量 */ if (sem-type SEM_TYPE_BINARY) { if (sem-count 0) { sem-count 1; } /* 二值信号量最多恢复到1防止连续give导致count超过1 */ } else { sem-count; } } arch_exit_critical(saved); if (need_sched) { schedule(); } return 0; }give的逻辑里最重要的设计决策是“优先唤醒等待者而不是增加count”。这么做的理由很微妙如果有一个任务在等待信号量你选择count而不是唤醒它那么这个等待任务不会被解除阻塞它依然停在等待队列里信号量也没有起到“资源转交”的作用。正确语义应该是有人等就先给人没人等才把资源放回池子。另外一个值得注意的点是被唤醒的任务拥有比当前任务更高的优先级时需要触发一次任务调度。在单核MCU上这种调度要放在临界区之外执行否则调度器运行时中断又是关闭的一旦新任务里又调用了take就可能出现死锁。3.4 等待队列的排序问题我在上面的代码里用的是list_add_tail把任务加到队尾看起来像FIFO。但实际生产级RTOS里等待队列通常不会简单地用FIFO而是按任务的优先级排序。原因很简单如果低优先级任务先去等一个信号量它排在队首高优先级任务后到只能排在它后面那么高优先级任务的等待时间会被低优先级任务拖长。这虽然不是严格意义上的优先级反转但会让高优先级任务的延迟变得不可控。按优先级插入的做法是遍历等待队列找到第一个优先级比当前任务低的位置把当前任务插到它前面。这个遍历在关中断区间内完成因为队列长度通常只有几个任务开销可以接受。miniOS里我把这个逻辑封装成prvAddTaskToWaitListtake里直接调用它而不是裸调list_add_tail。按优先级排序的等待队列还有一个额外好处give唤醒队首任务时天然就是唤醒当前等待者中优先级最高的那个省去了每次唤醒都要找最大优先级任务的麻烦。4. 任务同步实测两个LED严格交替闪烁4.1 需求分析纯延时方案为什么做不到我现在把需求说得更具体一点LED1亮100ms灭100ms不断循环LED2的行为必须严格跟随“LED1熄灭”这个事件——LED1一灭LED2立刻亮100ms然后熄灭等待LED1下一次熄灭再亮。如果用裸机延时任务a控制LED1翻转亮100ms灭100ms任务b控制LED2也遵循同样的时序。表面上看两个任务周期相同LED2总能跟LED1错开但实际跑起来问题很大第一个问题是任务启动顺序不确定task_b可能比task_a先运行那它的第一次亮灯就发生在LED1灭之前第二个问题是调度抖动两个任务的延时虽然都是100ms但从“延时结束”到“下一次真正切换回来执行”的延迟并不可控时间一长两个灯的相位就会慢慢漂移。正确的做法是用二值信号量做“事件通知”task_a完成了一个周期的动作之后give一个信号量task_b在信号量上take拿不到就一直等。这样task_b的每一次运行都被task_a的“通知”精确驱动相位永远对齐。4.2 用二值信号量实现的代码mini_sem_t sync_sem; void task_led1(void *arg) { for (;;) { LED1_ON(); delay_ms(100); LED1_OFF(); mini_sem_give(sync_sem); /* 通知task_led2我灭灯了 */ delay_ms(100); } } void task_led2(void *arg) { for (;;) { mini_sem_take(sync_sem, WAIT_FOREVER); /* 一直等到通知 */ LED2_ON(); delay_ms(100); LED2_OFF(); } }主函数里这样初始化mini_sem_init(sync_sem, SEM_TYPE_BINARY, 0); create_task(task_led1, ...); create_task(task_led2, ...); start_scheduler();注意这里二值信号量的初始count是0表示“事件还没有发生”。语义上take就是等待事件give就是发送事件跟“锁”的角色完全不同。这就是为什么我一直说二值信号量虽然结构上和互斥量相似但设计意图可以完全不同你要根据场景来设置初值。4.3 实测波形解读我把LED1和LED2接在逻辑分析仪上看波形整个运行过程非常清晰LED1灭的同时LED2的上升沿出现LED2灭掉后LED1也正好重新亮起两者严格错开相位不会漂移。更关键的是不管我把task_led2的优先级设置成比task_led1高还是低运行结果都一致。为什么因为task_led2在信号量上等待的时候是阻塞态根本不占CPU调度器不会把CPU分给它。只有等到task_led1给出信号量它才进入就绪态被调度器选中运行。这就是信号量做同步的最大价值它把“谁先谁后”这个问题从“靠任务创建顺序和优先级碰运气”变成了“由信号量的时序严格保证”。5. 资源共享实测用信号量保护串口打印和全局变量5.1 没有保护的串口打印现场我先故意写了个有问题的版本把串口打印直接放在任务里不加任何保护void task_a(void *arg) { for (;;) { printf([A] g_counter%d\n, g_counter); delay_ms(2); } } void task_b(void *arg) { for (;;) { printf([B] g_counter%d\n, g_counter--); delay_ms(3); } }跑一段时间控制台输出从乱七八糟开始甚至会出现把一行格式打断的情况。如果你把g_counter的读写放到打印语句外面去执行还能看到两个任务各自执行了几百次之后计数器的终值跟理论值对不上的现象这就是竞态条件造成的更新丢失。5.2 加一把信号量锁修复方案是把“读-改-写g_counter”和“打印整行”整体包进信号量临界区。注意这里二值信号量的初值必须设为1表示“锁是空闲的”。mini_sem_t print_sem; void task_a(void *arg) { for (;;) { mini_sem_take(print_sem, WAIT_FOREVER); printf([A] g_counter%d\n, g_counter); mini_sem_give(print_sem); delay_ms(2); } } void task_b(void *arg) { for (;;) { mini_sem_take(print_sem, WAIT_FOREVER); printf([B] g_counter%d\n, g_counter--); mini_sem_give(print_sem); delay_ms(3); } }加锁之后任何时刻系统里最多只有一个任务在执行printf另一任务如果也想打印就会在take处阻塞直到锁被释放。g_counter的读改写也不再有交叉因为整个区域是原子的。实践中有个重要经验锁的粒度要尽量小锁覆盖的代码要尽量短。上面这个例子里把打印也包进去是必要的因为整个printf输出的多行内容是一个整体拆开反而会乱。但如果你只是要保护一个全局变量的自增那就应该只锁那两三行赋值语句不要在锁里做耗时工作。5.3 临界区与信号量的取舍很多新手会问关中断也能保护共享资源为什么还要用信号量答案在于“粒度”和“代价”完全不同。关中断适合保护那些微秒级的短操作比如链表插入、队列读写。但它的代价是关掉了整个MCU的所有中断如果关中断时间太长会导致定时器中断、UART接收中断都错过对实时性反而是灾难。信号量则适合保护那些可能相对耗时的临界区比如printf、外设读写。因为信号量不屏蔽中断只是让其他任务阻塞等待中断依然可以及时响应。它的代价是如果锁被占用任务要经历一次“挂起-阻塞-唤醒”的调度过程这个切换开销比关中断大一些。所以能用短临界区解决的不用信号量信号量解决的问题也别想着用裸中断去硬扛。我实测过一个场景在GD32F103上跑两个任务每个任务都频繁打印加了信号量之后CPU占用多了大概百分之几但日志完全正常这个开销对大多数应用来说完全值。6. 中断与信号量ISR里只能give不能take6.1 为什么ISR里不能take嵌入式开发里经常出现这样的需求外部按键触发中断中断里设置一个标志然后让某个任务去处理按键事件。很多人的第一反应是在中断里调用mini_sem_take(sem, WAIT_FOREVER)把信号量拿住然后任务再give。这是非常严重的错误。原因是take在信号量不可用的时候会让当前任务进入阻塞态而中断上下文根本不属于任何任务。一旦在ISR里尝试阻塞等待这个RTOS的调度状态就彻底乱套了没有任务控制块可以被挂起current_task指向的是被中断打断的那个任务如果把它的状态改成阻塞那么被打断的任务永远无法恢复运行整个系统直接卡死在中断返回的那一刻。正确的规则只有一条中断服务函数里只能调用give的变体give_from_isr用来唤醒一个正在等待的任务绝对不能在中断里调用take。6.2 实现一个ISR安全的give版本uint32_t mini_sem_give_from_isr(mini_sem_t *sem, uint32_t *pxHigherPriorityTaskWoken) { task_t *task; uint32_t saved; *pxHigherPriorityTaskWoken 0; saved arch_enter_critical(); task list_first(sem-wait_list); if (task) { list_remove(task-list_node); task-state TASK_STATE_READY; task-take_result 0; add_to_ready_list(task); if (task-prio current_task-prio) { *pxHigherPriorityTaskWoken 1; } } else { if (sem-type SEM_TYPE_BINARY) { sem-count (sem-count 0) ? 1 : sem-count; } else { sem-count; } } arch_exit_critical(saved); return 0; }这个函数和普通give的逻辑几乎一样唯一的区别是它通过一个指针参数pxHigherPriorityTaskWoken把“是否唤醒了更高优先级任务”这个信息传出去而不是直接在函数内调用schedule。为什么不能在ISR里直接调用schedule因为中断返回时的任务切换需要遵循Cortex-M3的中断尾链机制直接调用会让CPU提前切换到新任务栈指针和异常返回帧的处理就乱了。正确做法是中断函数退出前检查这个标志如果为1就在中断返回前请求一次PendSV异常由PendSV来执行真正的上下文切换。这个机制在FreeRTOS里就叫“中断安全版本”我强烈建议所有手写RTOS实现都照这个思路来。6.3 一个完整的中断配合示例mini_sem_t key_sem; void EXTI0_IRQHandler(void) { uint32_t need_switch 0; ... mini_sem_give_from_isr(key_sem, need_switch); if (need_switch) { port_yield_from_isr(); /* 触发PendSV切换 */ } } void task_key_handler(void *arg) { for (;;) { mini_sem_take(key_sem, WAIT_FOREVER); printf(key pressed\r\n); } }这样一个模型就把“中断产生事件”和“任务处理事件”解耦了。中断里只做最少的操作实时的部分由高优先级任务去完成。这种写法在裸机里通常要用一个全局标志变量轮询来实现在RTOS里用信号量干净地搞定。7. 别把二值信号量当互斥量用优先级反转的坑7.1 一个真实会发生的反转场景二值信号量做互斥表面上看没有问题初值为1take拿锁give放锁。但这里埋着一个很深的坑叫优先级反转。假设系统里有三个任务任务H高优先级负责紧急控制逻辑任务M中优先级普通计算任务任务L低优先级偶尔访问慢速外设L先拿到了一个二值信号量锁正在操作某个共享外设。这时H就绪并尝试take同一个锁因为锁被L持有H被阻塞。如果此时M也进入就绪状态由于M的优先级高于L但低于H它会立刻抢占LL被挂起无法继续执行也就无法释放信号量。结果就是H明明优先级最高却被一个中优先级的M活活堵住要等M跑完才轮得到L继续L释放锁后H才能继续。这个“反转”的持续时间完全取决于M的执行时间可能在毫秒到秒级不定。优先级反转不是理论问题在真实项目里我见过因为这个问题导致看门狗复位的情况。所以正经RTOS里做互斥用的不是二值信号量而是专门的互斥量Mutex它带优先级继承机制。7.2 优先级继承的简化实现思路优先级继承的核心思想是当低优先级任务持有的锁被高优先级任务申请时临时把低优先级任务的优先级提升到高优先级任务同一水平等它释放锁后再恢复原优先级。这样M就再也抢不过LL得以尽快执行并释放锁H的等待时间被压缩到一个很短的区间。我给的miniOS互斥量结构如下typedef struct mini_mutex { task_t *owner; /* 当前持有锁的任务没有则为NULL */ uint32_t owner_prio; /* 记录持有者进入前的原始优先级释放锁时恢复 */ list_t wait_list; /* 等待该互斥量的任务队列 */ } mini_mutex_t;take的简化流程是如果owner为NULL说明锁空闲直接设置owner为当前任务记录owner_prio拿走锁。如果owner不是当前任务说明锁被占用了。检查当前任务优先级是否高于owner当前优先级如果是就把owner的优先级提升到当前任务优先级并把owner从就绪队列里取出来重新按新优先级插入。当前任务加入wait_list并阻塞。give的简化流程是从wait_list里取第一个任务作为新的owner。如果有新owner把它设为就绪态并让它获得锁。恢复原来owner的优先级到owner_prio重新放入就绪队列。void mini_mutex_take(mini_mutex_t *m) { if (m-owner NULL) { m-owner current_task; m-owner_prio current_task-prio; return; } if (m-owner current_task) { /* 同一任务重复拿锁要么支持递归要么直接报错 */ return; } /* 优先级继承等待者比持有者更重要先提升持有者 */ if (current_task-prio m-owner-prio) { m-owner-prio current_task-prio; update_ready_list(m-owner); } current_task-state TASK_STATE_BLOCKED; list_add_tail(m-wait_list, current_task-list_node); schedule(); } void mini_mutex_give(mini_mutex_t *m) { task_t *next list_first(m-wait_list); if (next) { list_remove(next-list_node); next-state TASK_STATE_READY; add_to_ready_list(next); m-owner next; m-owner_prio next-prio; } else { m-owner NULL; } /* 恢复原先持有者的优先级 */ current_task-prio m-owner_prio; update_ready_list(current_task); }这段代码是教学级简化版但已经足以打断优先级反转的链条。我在实际miniOS里还加了“递归锁”和“互斥量删除时唤醒所有等待者”的处理那些属于边界情况等你有项目真正需要时再补也不迟。7.3 什么时候该用互斥量什么时候用二值信号量我的建议很简单凡是“保护共享资源”这种场景一律用互斥量凡是“事件通知、任务同步”这种场景用二值信号量。虽然底层都能实现但互斥量的优先级继承属性是专门为锁设计的二值信号量没有这个属性。很多嵌入式教科书把这两个概念混着讲导致实际代码里踩了优先级反转的坑都不知道这是系列文章里我最想强调的一个点。8. 我踩过的几个坑和验证方法8.1 踩坑记录关中断时间太长导致定时器中断丢失我在给信号量加调试打印的时候习惯性地在take的临界区里放了一个LOG输出。结果SysTick定时器中断被屏蔽的时间超过了整整一个Tick周期系统的调度时钟直接漂移所有延时都变慢了。排查了好久才意识到是关中断区间太长。这个教训让我养成了习惯临界区代码要么只有几条内存操作指令要么就是调试版本里用一个计数器统计关中断时间上线前把调试打印全部拿掉。8.2 踩坑记录二值信号量连续give导致锁失效有一次我写了一个资源释放函数里面不管三七二十一先give一下信号量。结果一个任务释放了锁之后另一个任务也调用了givecount从0变到1然后两个任务同时take都成功了。共享资源同时被两个任务写BUG特别隐蔽。后来我把give的实现改成了“二值信号量只有在count0时才置1”并且给give加了一个内部断言如果二值信号量在被give之前count已经是1就立刻触发错误处理。虽然正常情况下不该出现这种调用但防御性编程能帮你尽早发现问题。8.3 验证方法GPIO翻转加逻辑分析仪手写RTOS没有调试器辅助的情况下我最常用的验证方法是在关键路径上翻转一个GPIO然后用逻辑分析仪抓波形。比如在take的临界区前后各翻转一次某个引脚测量脉冲宽度就能知道临界区关闭了多久中断在两个LED同步测试中直接抓LED引脚的上升沿和下降沿就能判断任务同步是否严格。另一个很实用的指标是“最大关中断时间”用一段高优先级中断来测量起一个定时器中断让它每次都记录从进入中断到退出中断的时间差如果这个时间差波动很大就说明某处关中断时间过长。把信号量的实现从内到外测一遍什么问题都藏不住。8.4 一个简单的压测脚本多任务争抢信号量我最后一次验收信号量模块时写了一个压力测试创建5个任务优先级各不相同每个任务循环10000次每次take锁后对一个全局计数器做100次自增再give。理论值在单核下应该是严格串行的如果出现计数偏差说明锁失效。这个测试跑通的瞬间我基本可以确定信号量的实现是可靠的。volatile uint32_t g_protected_counter 0; void stress_task(void *arg) { for (int i 0; i 10000; i) { mini_sem_take(mutex, WAIT_FOREVER); for (int j 0; j 100; j) { g_protected_counter; } mini_sem_give(mutex); } /* 结束后打印自己的完成标志 */ }5个任务全部跑完后g_protected_counter的值必须是10000 * 100 * 5 5000000。只要结果不是这个数就说明存在竞态漏洞。我在调这段压测代码的时候还真抓出过一个bug等待队列在按优先级插入时没有处理“优先级相同”的情况导致两个同优先级任务互相插队某个任务一直得不到唤醒最终整个系统卡住。后来我把插入逻辑改成“同优先级任务排在后面”这个问题才消失。信号量写完其实你已经跨过了RTOS内核里最难理解的一道门槛。它背后涉及的不只是那几行链表和计数逻辑更是“临界区、阻塞、唤醒、调度时机”这一整套思维模型。接下来你可以继续往更高级的方向走——互斥量的优先级继承、消息队列、事件标志组这些组件本质上都是在信号量这个“资源数加等待队列”的骨架上做扩展。你在两个LED和一个串口上把信号量彻底玩明白后面不管用什么商用RTOS再看到它内部的信号量实现都会有一种“原来如此”的熟悉感。 手写RTOS内核：信号量实现原理与任务同步实战
这个手搓RTOS的系列写到第8篇。前面几篇我们把任务切换、延时、调度器都跑通了LED灯也能按照任务函数里的延时各自闪起来。但真到了这一步你会发现一个很尴尬的事实两个任务只要开始“配合干活”光靠延时函数根本写不出正确的逻辑。你要么看到串口日志乱成一团要么发现一个任务总是抢先一步导致整个状态错乱。信号量就是专门来解决这些问题的它是RTOS里任务同步与资源共享的基石也是我们从“点灯大师”往真正操作系统开发者迈进的关键一环。这篇文章我会从零开始围绕信号量的内核模型、take/give核心实现、任务同步实测、资源共享实测、中断安全设计、优先级反转这几个方向把信号量的方方面面拆开讲透。适合正在跟我一样手写RTOS的朋友也适合已经用过FreeRTOS等现成系统但想搞清楚信号量底层原理的开发者。就算你完全没接触过操作系统只要会C语言和一点链表操作也能跟着把信号量写出来跑起来。1. 点灯难度升级前先想清楚一个问题任务之间到底在抢什么1.1 第一阶段你的第一个多任务点灯程序其实什么都没抢很多人的RTOS入门第一课都是点灯。比如创建两个任务task_led1每300ms翻转一次LED1task_led2每500ms翻转一次LED2系统跑起来之后两个灯各闪各的看着很热闹。这时候你会觉得用RTOS也不过如此不就是把while循环拆成几个函数嘛用裸机延时也差不多能做。但这里有个容易忽略的事实这两个任务能互不干扰地运行是因为它们之间根本没有共享任何数据。LED1的GPIO寄存器地址虽然在底层只有一个但你在两个任务里翻转的是不同的PIN位底层硬件也不存在“同时写一个位”的竞争窗口所以裸机也能跑多个任务也能跑。也就是说你还没遇到RTOS真正要解决的问题。1.2 第二阶段从“各亮各的”变成“一起干活”就出事了一旦任务之间需要共享数据或协调时序问题立刻冒出来。举个最常见的例子两个任务都要通过同一个UART打印调试信息。task_a每秒打印一行温度task_b每2秒打印一行湿度单独看逻辑没问题但跑起来你会看到这样的输出temp25 hum60 temp26 hum61 temp27偶尔还会出现一行输出被切断的情况比如hum6后面直接跟了temp2整行日志彻底错乱。原因很简单printf内部是分多次往UART发送寄存器写数据的task_a刚写到一半时间片到了task_b抢占了CPU也往同一个UART寄存器写数据两个任务的字符就交织在一起了。再举一个更隐蔽的例子两个任务共同维护一个全局变量g_counter一个做g_counter另一个做g_counter--。在C语言里g_counter不是一条机器指令在Cortex-M3上它至少是“读内存-加一-写内存”三步。如果task_a读完旧值还没写回task_b已经完成了它的修改最后写回的那个任务会把对方的修改覆盖掉这个变量就丢了更新而且问题极难复现。这种问题有个专门的名字叫竞态条件Race Condition。1.3 我总结下来的三类经典症状问题类型表面现象根因互斥失败竞态串口日志乱码、共享计数不对、数据被覆盖多个任务同时进入了临界资源区同步丢失任务B在任务A发出数据之前就启动拿到的是旧状态任务之间有先后依赖但没有任何机制强制顺序死锁任务假装不运行了系统整体卡死看门狗乱叫任务等了一个永远等不到的信号量或者锁的获取顺序写反这三个问题信号量都能治只是用法不一样互斥问题用“二值信号量当作锁”来治同步问题用“二值信号量当作事件通知”来治生产消费问题用“计数信号量”来治。后面每个场景我都会给实测代码。2. 信号量的内核模型一个计数值加一条等待队列2.1 用餐厅叫号系统理解信号量信号量这个名字起得挺玄乎但它的内核模型特别简单就两个东西一个count计数器和一条等待队列。我习惯用餐厅叫号来类比。餐厅门口有个取号机当前号码是8号这就相当于count 1还有1个“可用资源”即8号还没被叫到。取号这个动作就是take如果还有可用号码拿一个走count减一如果没有可用号码了你就得在等待区排队这就对应把当前任务挂到信号量的等待队列上。叫号这个动作就是give服务员喊“8号请用餐”如果有人在等待就先让队首的人进去count不变如果没人等号码池里的可用号码就会增加count加一。把这个模型落到代码上信号量的“资源”不一定是某种实物它可以是“一把锁的占用权”也可以是“某个事件是否发生”的标记。这也是为什么信号量既能做互斥又能做同步因为它本质上就是一种“资源数量等待者队列”的通用的内核对象。2.2 二值信号量与计数信号量的本质区别信号量按最大计数值分为二值信号量Binary Semaphore和计数信号量Counting Semaphore。这个区别必须在设计数据结构的时候就留好字段后面实现才有依据。维度二值信号量计数信号量最大计数值1NN大于1初始值常见设置1表示锁空闲0表示事件未发生N表示N个可用资源典型用途互斥锁、任务间事件通知资源池管理、生产者-消费者模型实现注意give时count不能超过1否则锁会失效count可以累加到N注意别溢出很多初学者觉得二值信号量就是count最大为1的计数信号量这个理解本身没错但你要注意一个坑二值信号量被用做互斥锁时如果写give的代码没有加“最大为1”的限制一旦某个bug导致连续give了两次count会变成2此时两个任务同时都能拿到锁互斥保护直接失效。这个我在后面代码实现里会重点处理。2.3 我设计的miniOS信号量结构体我在自己的miniOS里把信号量定义成这样的结构体#define SEM_TYPE_BINARY 0 #define SEM_TYPE_COUNT 1 typedef struct mini_sem { uint8_t type; /* 二值还是计数 */ uint32_t count; /* 当前可用资源数 */ list_t wait_list; /* 等待该信号量的任务队列 */ } mini_sem_t;每个字段的作用都很直白。type决定give时要不要把count限制在1count是信号量最核心的状态初值由用户设置wait_list是一个双向链表链表的每一个节点对应一个因为拿不到信号量而陷入阻塞态的任务控制块。这里有个设计细节值得提一下任务控制块TCB里要么持有链表节点要么直接作为链表节点被串起来。我采取的是TCB内嵌list_node的方式也就是说等待队列存的是TCB节点本身这样从队列上摘下一个节点时就能直接拿到那个任务的所有信息不用再做一次“节点地址到任务地址”的反查。初始化函数也很简单void mini_sem_init(mini_sem_t *sem, uint8_t type, uint32_t init_count) { sem-type type; sem-count init_count; list_init(sem-wait_list); }初始化信号量的时机一定要在任何一个任务使用它之前否则会出现某个任务已经在等待了但wait_list还没有初始化的未定义行为。在RTOS的世界里“先初始化再用”是铁律。3. 手写核心原语take和give的完整实现3.1 为什么必须先关中断信号量的take和give看起来只有几行逻辑但它们不是普通函数它们操作的数据结构可能被多个任务同时访问。比如task_a正要执行count--指令还没执行完SysTick中断触发了调度器把task_b切换进来了task_b也执行到count--这时候count的修改就乱了。要保证“检查count-修改count-决定是否挂起”这个过程不被打断最简单的办法就是关中断。在Cortex-M3上可以通过设置PRIMASK寄存器来屏蔽所有可屏蔽中断实现一个原子临界区。临界区里面做的事情越少越好只做必要的队列操作和状态修改绝对不要把printf、复杂运算这种耗时操作放进去。我在miniOS里封装了两个宏#define arch_enter_critical() arch_disable_irq() /* 关中断 */ #define arch_exit_critical() arch_enable_irq() /* 开中断 */在实际项目里enter返回当前的PRIMASK状态exit时恢复而不是无条件打开这样可以支持临界区嵌套调用。这里的嵌套场景以后写互斥量、调试打印的时候会碰到建议一次做对。3.2 take的核心实现uint32_t mini_sem_take(mini_sem_t *sem, uint32_t timeout) { uint32_t saved; task_t *cur; saved arch_enter_critical(); /* 还有可用资源直接拿到 */ if (sem-count 0) { sem-count--; arch_exit_critical(saved); return 0; /* 返回0表示获取成功 */ } /* 没有资源并且不打算等立即失败返回 */ if (timeout 0) { arch_exit_critical(saved); return 1; /* 返回非0表示获取失败 */ } /* 把自己挂到等待队列上等别人give */ cur current_task; cur-state TASK_STATE_BLOCKED; cur-wait_sem sem; cur-take_result 1; /* 先默认失败被唤醒后give会改成0 */ list_add_tail(sem-wait_list, cur-list_node); arch_exit_critical(saved); /* 主动让出CPU切换去执行其他任务 */ schedule(); /* 被唤醒后回到这里返回结果 */ return cur-take_result; }这段代码有几个关键点。第一count 0和count--必须在同一个临界区内完成否则两个任务可能同时看到count等于1然后各自减一最后两个任务都觉得自己拿到资源了。第二当count为0且timeout不为0时任务不能一直占着CPU空转它必须主动调用schedule()让出处理器。这就是RTOS里“阻塞态”的由来任务把自己放到等待队列上然后不再参与调度直到有人唤醒它。第三我在挂起前先把cur-take_result置为1意思是“如果没人来叫我我就一直等直到give把我唤醒并告诉我成功为止”。为什么不在pending之后设置为0因为give可能会在另一个任务上下文里修改这个任务控制块的字段所以唤醒逻辑里会负责把take_result改成0这样当前任务被切换回来之后直接读这个字段就行。3.3 give的核心实现uint32_t mini_sem_give(mini_sem_t *sem) { uint32_t saved; task_t *task; uint32_t need_sched 0; saved arch_enter_critical(); /* 有任务在等待直接把资源转交给队首任务 */ task list_first(sem-wait_list); if (task) { list_remove(task-list_node); task-state TASK_STATE_READY; task-take_result 0; /* 告诉它拿到了 */ add_to_ready_list(task); if (task-prio current_task-prio) { need_sched 1; /* 被唤醒的任务优先级更高需要切换 */ } } else { /* 没有任务等待资源归还给信号量 */ if (sem-type SEM_TYPE_BINARY) { if (sem-count 0) { sem-count 1; } /* 二值信号量最多恢复到1防止连续give导致count超过1 */ } else { sem-count; } } arch_exit_critical(saved); if (need_sched) { schedule(); } return 0; }give的逻辑里最重要的设计决策是“优先唤醒等待者而不是增加count”。这么做的理由很微妙如果有一个任务在等待信号量你选择count而不是唤醒它那么这个等待任务不会被解除阻塞它依然停在等待队列里信号量也没有起到“资源转交”的作用。正确语义应该是有人等就先给人没人等才把资源放回池子。另外一个值得注意的点是被唤醒的任务拥有比当前任务更高的优先级时需要触发一次任务调度。在单核MCU上这种调度要放在临界区之外执行否则调度器运行时中断又是关闭的一旦新任务里又调用了take就可能出现死锁。3.4 等待队列的排序问题我在上面的代码里用的是list_add_tail把任务加到队尾看起来像FIFO。但实际生产级RTOS里等待队列通常不会简单地用FIFO而是按任务的优先级排序。原因很简单如果低优先级任务先去等一个信号量它排在队首高优先级任务后到只能排在它后面那么高优先级任务的等待时间会被低优先级任务拖长。这虽然不是严格意义上的优先级反转但会让高优先级任务的延迟变得不可控。按优先级插入的做法是遍历等待队列找到第一个优先级比当前任务低的位置把当前任务插到它前面。这个遍历在关中断区间内完成因为队列长度通常只有几个任务开销可以接受。miniOS里我把这个逻辑封装成prvAddTaskToWaitListtake里直接调用它而不是裸调list_add_tail。按优先级排序的等待队列还有一个额外好处give唤醒队首任务时天然就是唤醒当前等待者中优先级最高的那个省去了每次唤醒都要找最大优先级任务的麻烦。4. 任务同步实测两个LED严格交替闪烁4.1 需求分析纯延时方案为什么做不到我现在把需求说得更具体一点LED1亮100ms灭100ms不断循环LED2的行为必须严格跟随“LED1熄灭”这个事件——LED1一灭LED2立刻亮100ms然后熄灭等待LED1下一次熄灭再亮。如果用裸机延时任务a控制LED1翻转亮100ms灭100ms任务b控制LED2也遵循同样的时序。表面上看两个任务周期相同LED2总能跟LED1错开但实际跑起来问题很大第一个问题是任务启动顺序不确定task_b可能比task_a先运行那它的第一次亮灯就发生在LED1灭之前第二个问题是调度抖动两个任务的延时虽然都是100ms但从“延时结束”到“下一次真正切换回来执行”的延迟并不可控时间一长两个灯的相位就会慢慢漂移。正确的做法是用二值信号量做“事件通知”task_a完成了一个周期的动作之后give一个信号量task_b在信号量上take拿不到就一直等。这样task_b的每一次运行都被task_a的“通知”精确驱动相位永远对齐。4.2 用二值信号量实现的代码mini_sem_t sync_sem; void task_led1(void *arg) { for (;;) { LED1_ON(); delay_ms(100); LED1_OFF(); mini_sem_give(sync_sem); /* 通知task_led2我灭灯了 */ delay_ms(100); } } void task_led2(void *arg) { for (;;) { mini_sem_take(sync_sem, WAIT_FOREVER); /* 一直等到通知 */ LED2_ON(); delay_ms(100); LED2_OFF(); } }主函数里这样初始化mini_sem_init(sync_sem, SEM_TYPE_BINARY, 0); create_task(task_led1, ...); create_task(task_led2, ...); start_scheduler();注意这里二值信号量的初始count是0表示“事件还没有发生”。语义上take就是等待事件give就是发送事件跟“锁”的角色完全不同。这就是为什么我一直说二值信号量虽然结构上和互斥量相似但设计意图可以完全不同你要根据场景来设置初值。4.3 实测波形解读我把LED1和LED2接在逻辑分析仪上看波形整个运行过程非常清晰LED1灭的同时LED2的上升沿出现LED2灭掉后LED1也正好重新亮起两者严格错开相位不会漂移。更关键的是不管我把task_led2的优先级设置成比task_led1高还是低运行结果都一致。为什么因为task_led2在信号量上等待的时候是阻塞态根本不占CPU调度器不会把CPU分给它。只有等到task_led1给出信号量它才进入就绪态被调度器选中运行。这就是信号量做同步的最大价值它把“谁先谁后”这个问题从“靠任务创建顺序和优先级碰运气”变成了“由信号量的时序严格保证”。5. 资源共享实测用信号量保护串口打印和全局变量5.1 没有保护的串口打印现场我先故意写了个有问题的版本把串口打印直接放在任务里不加任何保护void task_a(void *arg) { for (;;) { printf([A] g_counter%d\n, g_counter); delay_ms(2); } } void task_b(void *arg) { for (;;) { printf([B] g_counter%d\n, g_counter--); delay_ms(3); } }跑一段时间控制台输出从乱七八糟开始甚至会出现把一行格式打断的情况。如果你把g_counter的读写放到打印语句外面去执行还能看到两个任务各自执行了几百次之后计数器的终值跟理论值对不上的现象这就是竞态条件造成的更新丢失。5.2 加一把信号量锁修复方案是把“读-改-写g_counter”和“打印整行”整体包进信号量临界区。注意这里二值信号量的初值必须设为1表示“锁是空闲的”。mini_sem_t print_sem; void task_a(void *arg) { for (;;) { mini_sem_take(print_sem, WAIT_FOREVER); printf([A] g_counter%d\n, g_counter); mini_sem_give(print_sem); delay_ms(2); } } void task_b(void *arg) { for (;;) { mini_sem_take(print_sem, WAIT_FOREVER); printf([B] g_counter%d\n, g_counter--); mini_sem_give(print_sem); delay_ms(3); } }加锁之后任何时刻系统里最多只有一个任务在执行printf另一任务如果也想打印就会在take处阻塞直到锁被释放。g_counter的读改写也不再有交叉因为整个区域是原子的。实践中有个重要经验锁的粒度要尽量小锁覆盖的代码要尽量短。上面这个例子里把打印也包进去是必要的因为整个printf输出的多行内容是一个整体拆开反而会乱。但如果你只是要保护一个全局变量的自增那就应该只锁那两三行赋值语句不要在锁里做耗时工作。5.3 临界区与信号量的取舍很多新手会问关中断也能保护共享资源为什么还要用信号量答案在于“粒度”和“代价”完全不同。关中断适合保护那些微秒级的短操作比如链表插入、队列读写。但它的代价是关掉了整个MCU的所有中断如果关中断时间太长会导致定时器中断、UART接收中断都错过对实时性反而是灾难。信号量则适合保护那些可能相对耗时的临界区比如printf、外设读写。因为信号量不屏蔽中断只是让其他任务阻塞等待中断依然可以及时响应。它的代价是如果锁被占用任务要经历一次“挂起-阻塞-唤醒”的调度过程这个切换开销比关中断大一些。所以能用短临界区解决的不用信号量信号量解决的问题也别想着用裸中断去硬扛。我实测过一个场景在GD32F103上跑两个任务每个任务都频繁打印加了信号量之后CPU占用多了大概百分之几但日志完全正常这个开销对大多数应用来说完全值。6. 中断与信号量ISR里只能give不能take6.1 为什么ISR里不能take嵌入式开发里经常出现这样的需求外部按键触发中断中断里设置一个标志然后让某个任务去处理按键事件。很多人的第一反应是在中断里调用mini_sem_take(sem, WAIT_FOREVER)把信号量拿住然后任务再give。这是非常严重的错误。原因是take在信号量不可用的时候会让当前任务进入阻塞态而中断上下文根本不属于任何任务。一旦在ISR里尝试阻塞等待这个RTOS的调度状态就彻底乱套了没有任务控制块可以被挂起current_task指向的是被中断打断的那个任务如果把它的状态改成阻塞那么被打断的任务永远无法恢复运行整个系统直接卡死在中断返回的那一刻。正确的规则只有一条中断服务函数里只能调用give的变体give_from_isr用来唤醒一个正在等待的任务绝对不能在中断里调用take。6.2 实现一个ISR安全的give版本uint32_t mini_sem_give_from_isr(mini_sem_t *sem, uint32_t *pxHigherPriorityTaskWoken) { task_t *task; uint32_t saved; *pxHigherPriorityTaskWoken 0; saved arch_enter_critical(); task list_first(sem-wait_list); if (task) { list_remove(task-list_node); task-state TASK_STATE_READY; task-take_result 0; add_to_ready_list(task); if (task-prio current_task-prio) { *pxHigherPriorityTaskWoken 1; } } else { if (sem-type SEM_TYPE_BINARY) { sem-count (sem-count 0) ? 1 : sem-count; } else { sem-count; } } arch_exit_critical(saved); return 0; }这个函数和普通give的逻辑几乎一样唯一的区别是它通过一个指针参数pxHigherPriorityTaskWoken把“是否唤醒了更高优先级任务”这个信息传出去而不是直接在函数内调用schedule。为什么不能在ISR里直接调用schedule因为中断返回时的任务切换需要遵循Cortex-M3的中断尾链机制直接调用会让CPU提前切换到新任务栈指针和异常返回帧的处理就乱了。正确做法是中断函数退出前检查这个标志如果为1就在中断返回前请求一次PendSV异常由PendSV来执行真正的上下文切换。这个机制在FreeRTOS里就叫“中断安全版本”我强烈建议所有手写RTOS实现都照这个思路来。6.3 一个完整的中断配合示例mini_sem_t key_sem; void EXTI0_IRQHandler(void) { uint32_t need_switch 0; ... mini_sem_give_from_isr(key_sem, need_switch); if (need_switch) { port_yield_from_isr(); /* 触发PendSV切换 */ } } void task_key_handler(void *arg) { for (;;) { mini_sem_take(key_sem, WAIT_FOREVER); printf(key pressed\r\n); } }这样一个模型就把“中断产生事件”和“任务处理事件”解耦了。中断里只做最少的操作实时的部分由高优先级任务去完成。这种写法在裸机里通常要用一个全局标志变量轮询来实现在RTOS里用信号量干净地搞定。7. 别把二值信号量当互斥量用优先级反转的坑7.1 一个真实会发生的反转场景二值信号量做互斥表面上看没有问题初值为1take拿锁give放锁。但这里埋着一个很深的坑叫优先级反转。假设系统里有三个任务任务H高优先级负责紧急控制逻辑任务M中优先级普通计算任务任务L低优先级偶尔访问慢速外设L先拿到了一个二值信号量锁正在操作某个共享外设。这时H就绪并尝试take同一个锁因为锁被L持有H被阻塞。如果此时M也进入就绪状态由于M的优先级高于L但低于H它会立刻抢占LL被挂起无法继续执行也就无法释放信号量。结果就是H明明优先级最高却被一个中优先级的M活活堵住要等M跑完才轮得到L继续L释放锁后H才能继续。这个“反转”的持续时间完全取决于M的执行时间可能在毫秒到秒级不定。优先级反转不是理论问题在真实项目里我见过因为这个问题导致看门狗复位的情况。所以正经RTOS里做互斥用的不是二值信号量而是专门的互斥量Mutex它带优先级继承机制。7.2 优先级继承的简化实现思路优先级继承的核心思想是当低优先级任务持有的锁被高优先级任务申请时临时把低优先级任务的优先级提升到高优先级任务同一水平等它释放锁后再恢复原优先级。这样M就再也抢不过LL得以尽快执行并释放锁H的等待时间被压缩到一个很短的区间。我给的miniOS互斥量结构如下typedef struct mini_mutex { task_t *owner; /* 当前持有锁的任务没有则为NULL */ uint32_t owner_prio; /* 记录持有者进入前的原始优先级释放锁时恢复 */ list_t wait_list; /* 等待该互斥量的任务队列 */ } mini_mutex_t;take的简化流程是如果owner为NULL说明锁空闲直接设置owner为当前任务记录owner_prio拿走锁。如果owner不是当前任务说明锁被占用了。检查当前任务优先级是否高于owner当前优先级如果是就把owner的优先级提升到当前任务优先级并把owner从就绪队列里取出来重新按新优先级插入。当前任务加入wait_list并阻塞。give的简化流程是从wait_list里取第一个任务作为新的owner。如果有新owner把它设为就绪态并让它获得锁。恢复原来owner的优先级到owner_prio重新放入就绪队列。void mini_mutex_take(mini_mutex_t *m) { if (m-owner NULL) { m-owner current_task; m-owner_prio current_task-prio; return; } if (m-owner current_task) { /* 同一任务重复拿锁要么支持递归要么直接报错 */ return; } /* 优先级继承等待者比持有者更重要先提升持有者 */ if (current_task-prio m-owner-prio) { m-owner-prio current_task-prio; update_ready_list(m-owner); } current_task-state TASK_STATE_BLOCKED; list_add_tail(m-wait_list, current_task-list_node); schedule(); } void mini_mutex_give(mini_mutex_t *m) { task_t *next list_first(m-wait_list); if (next) { list_remove(next-list_node); next-state TASK_STATE_READY; add_to_ready_list(next); m-owner next; m-owner_prio next-prio; } else { m-owner NULL; } /* 恢复原先持有者的优先级 */ current_task-prio m-owner_prio; update_ready_list(current_task); }这段代码是教学级简化版但已经足以打断优先级反转的链条。我在实际miniOS里还加了“递归锁”和“互斥量删除时唤醒所有等待者”的处理那些属于边界情况等你有项目真正需要时再补也不迟。7.3 什么时候该用互斥量什么时候用二值信号量我的建议很简单凡是“保护共享资源”这种场景一律用互斥量凡是“事件通知、任务同步”这种场景用二值信号量。虽然底层都能实现但互斥量的优先级继承属性是专门为锁设计的二值信号量没有这个属性。很多嵌入式教科书把这两个概念混着讲导致实际代码里踩了优先级反转的坑都不知道这是系列文章里我最想强调的一个点。8. 我踩过的几个坑和验证方法8.1 踩坑记录关中断时间太长导致定时器中断丢失我在给信号量加调试打印的时候习惯性地在take的临界区里放了一个LOG输出。结果SysTick定时器中断被屏蔽的时间超过了整整一个Tick周期系统的调度时钟直接漂移所有延时都变慢了。排查了好久才意识到是关中断区间太长。这个教训让我养成了习惯临界区代码要么只有几条内存操作指令要么就是调试版本里用一个计数器统计关中断时间上线前把调试打印全部拿掉。8.2 踩坑记录二值信号量连续give导致锁失效有一次我写了一个资源释放函数里面不管三七二十一先give一下信号量。结果一个任务释放了锁之后另一个任务也调用了givecount从0变到1然后两个任务同时take都成功了。共享资源同时被两个任务写BUG特别隐蔽。后来我把give的实现改成了“二值信号量只有在count0时才置1”并且给give加了一个内部断言如果二值信号量在被give之前count已经是1就立刻触发错误处理。虽然正常情况下不该出现这种调用但防御性编程能帮你尽早发现问题。8.3 验证方法GPIO翻转加逻辑分析仪手写RTOS没有调试器辅助的情况下我最常用的验证方法是在关键路径上翻转一个GPIO然后用逻辑分析仪抓波形。比如在take的临界区前后各翻转一次某个引脚测量脉冲宽度就能知道临界区关闭了多久中断在两个LED同步测试中直接抓LED引脚的上升沿和下降沿就能判断任务同步是否严格。另一个很实用的指标是“最大关中断时间”用一段高优先级中断来测量起一个定时器中断让它每次都记录从进入中断到退出中断的时间差如果这个时间差波动很大就说明某处关中断时间过长。把信号量的实现从内到外测一遍什么问题都藏不住。8.4 一个简单的压测脚本多任务争抢信号量我最后一次验收信号量模块时写了一个压力测试创建5个任务优先级各不相同每个任务循环10000次每次take锁后对一个全局计数器做100次自增再give。理论值在单核下应该是严格串行的如果出现计数偏差说明锁失效。这个测试跑通的瞬间我基本可以确定信号量的实现是可靠的。volatile uint32_t g_protected_counter 0; void stress_task(void *arg) { for (int i 0; i 10000; i) { mini_sem_take(mutex, WAIT_FOREVER); for (int j 0; j 100; j) { g_protected_counter; } mini_sem_give(mutex); } /* 结束后打印自己的完成标志 */ }5个任务全部跑完后g_protected_counter的值必须是10000 * 100 * 5 5000000。只要结果不是这个数就说明存在竞态漏洞。我在调这段压测代码的时候还真抓出过一个bug等待队列在按优先级插入时没有处理“优先级相同”的情况导致两个同优先级任务互相插队某个任务一直得不到唤醒最终整个系统卡住。后来我把插入逻辑改成“同优先级任务排在后面”这个问题才消失。信号量写完其实你已经跨过了RTOS内核里最难理解的一道门槛。它背后涉及的不只是那几行链表和计数逻辑更是“临界区、阻塞、唤醒、调度时机”这一整套思维模型。接下来你可以继续往更高级的方向走——互斥量的优先级继承、消息队列、事件标志组这些组件本质上都是在信号量这个“资源数加等待队列”的骨架上做扩展。你在两个LED和一个串口上把信号量彻底玩明白后面不管用什么商用RTOS再看到它内部的信号量实现都会有一种“原来如此”的熟悉感。