任务通知比二值信号量快，因其直接操作任务TCB中的ulNotifiedValue字段和状态位，无需内存分配、临界区嵌套或列表重排序，实测开销仅12–18周期，远低于信号量组合的150+周期。
为什么任务通知比二值信号量快
FreeRTOS 的 vTaskNotifyGive() 和 xTaskNotifyWait() 不经过队列或事件组的通用调度路径，直接操作目标任务的 ulNotifiedValue 字段和等待状态位。没有内存分配、没有临界区嵌套、不触发列表重排序——实测在 Cortex-M4 上单次通知开销约 12–18 个周期，而 xSemaphoreGive() + xSemaphoreTake() 组合通常要 150+ 周期。
关键限制：一个任务只能有一个通知值，且不能像信号量那样被多个任务同时等待（除非用“广播”模式，但仍有语义差异）。
如何用 xTaskNotifyWait() 等效替代二值信号量的阻塞等待
典型场景：任务 A 等待任务 B 完成某件事（如 DMA 传输结束），B 通过通知唤醒 A。这里不需要“计数”，只需“脉冲式唤醒”。
- 任务 A 调用
xTaskNotifyWait(0x00, 0x00, NULL, portMAX_DELAY)—— 清除所有位、不检查任何位、不关心通知值、永久等待 - 任务 B 执行
xTaskNotifyGive(xHandleOfTaskA)或更精确的xTaskNotify(xHandleOfTaskA, 0, eNotifyAction::eNoAction) - 注意：
xTaskNotifyGive()是中断安全的；xTaskNotify()在中断中需用带FromISR后缀的版本
中断服务程序（ISR）里怎么安全发通知
这是最容易出错的地方：直接在 ISR 中调用非 FromISR 版本会破坏内核状态，可能卡死或跳飞。
立即学习“C++免费学习笔记（深入）”；
- 必须使用
xTaskNotifyGiveFromISR()或xTaskNotifyFromISR() - 必须传入
pxHigherPriorityTaskWoken指针，并在调用后检查它是否被置为pdTRUE，若是则需在退出 ISR 前调用portYIELD_FROM_ISR() - 示例片段（在 UART 接收完成 ISR 中）：
BaseType_t xHigherPriorityTaskWoken = pdFALSE; xTaskNotifyGiveFromISR(xRxTaskHandle, &xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
任务通知和二值信号量行为差异的关键点
它们不是 1:1 替换关系。忽略这些差异会导致逻辑错误或死锁：
- 通知是“单次有效”的：如果接收任务尚未等待，通知就已发出，则该次通知丢失（信号量会累积一次）
- 没有“自动清零”机制：
xTaskNotifyWait()返回后，通知值仍存在，下次调用若不设ulBitsToClearOnEntry可能立即返回 - 无法跨任务共享：每个任务只能被自己专属的通知值唤醒，不能像信号量句柄那样被任意任务
Give - 调试困难：GDB / J-Link 无法直接观察通知值，需靠日志或自定义钩子函数打点
真正需要加速的场景，往往也是对时序最敏感的——这时候多花两分钟确认通知是否被漏收、是否在错误上下文调用，比后期抓 hardfault 更省时间。
