// 就这个函数，让我debug了三个小时 void vTaskA(void *pvParameters) { uint32_t ulNotifiedValue; for(;;) { ulNotifiedValue = ulTaskNotifyTake(pdTRUE, portMAX_DELAY); if(ulNotifiedValue > 5) { process_batch(ulNotifiedValue); } } }上周做一个小项目，两个task之间传数据，我第一反应就是上信号量。毕竟从学RTOS第一天开始，老师就告诉你信号量是用来同步的嘛。结果写完后发现一个问题——高频场景下，信号量带来的上下文切换开销比我预想的大得多。
然后翻了一下FreeRTOS的手册，发现有个叫Task Notification的东西，从V8.2.0就有了。说实话我之前一直以为这玩意儿就是个阉割版信号量，根本没当回事。直到这次被逼到墙角，仔细看了一遍，才发现——这东西才是亲儿子。
对比一下就知道了。如果用二进制信号量做同步，你得先creat一个Semaphore，然后give/take。光create这一步就要走一遍队列机制，消息传递路径大概是：task→queue→另一个task。中间怎么也得走好几个函数调用。
换成Task Notification呢？
// Task A - 发送方 xTaskNotifyGive(xTaskBHandle); // Task B - 接收方 ulTaskNotifyTake(pdTRUE, pdMS_TO_TICKS(100));就这两行。没有额外的queue创建，没有多余的IPC对象。每个TCB里本来就预留了一个32位的notification value和state，完全零额外开销。调用xTaskNotifyGive本质上就是在目标task的TCB里写一个值，然后检查一下优先级——如果对方的优先级比自己高就立刻切换。
我之前做的一个项目，每秒要处理几千次事件同步，用信号量写出来功能没问题，但是用示波器抓了一下任务切换的频率，明显偏高。换了Task Notification之后，单看任务切换次数至少降了三分之一。
不过这东西有个坑。它的工作方式跟信号量有个本质区别——信号量是"独立的同步对象"，而Task Notification是"绑定在task上的"。意思就是，你没办法用一个Notification去同步多个task。Notification是一对一的：一个特定的task只能被一个sender通知。如果你想做一对多、多对一、多对多这种复杂的同步拓扑，Notification就不够用了，得老老实实上队列或者事件组。
还有一个容易翻车的地方——Notification value溢出。
// 坑人的场景 void vSender(void *pvParameters) { for(;;) { // 连续调用give多次 xTaskNotifyGive(xReceiverHandle); xTaskNotifyGive(xReceiverHandle); xTaskNotifyGive(xReceiverHandle); vTaskDelay(pdMS_TO_TICKS(1)); } } void vReceiver(void *pvParameters) { for(;;) { // 这里take一次，以为只少了一个count uint32_t count = ulTaskNotifyTake(pdFALSE, portMAX_DELAY); // pdFALSE表示不管累积了多少，只取一次 // 实际丢了多少个通知，你根本不知道 } }注意ulTaskNotifyTake的第二个参数。pdTRUE是一次性清空，拿到累积的所有通知次数；pdFALSE是只取1，剩下的不清空。很多人以为pdFALSE会按信号量的方式一个一个消费，实际上它只是"拿1个，不清空计数"——如果你发得快收得慢，notification value会一直往上堆，直到0xFFFFFFFF然后溢出归零。别问我怎么知道的。
所以如果你用Notification来做counting semaphore的替代品，一定要想清楚你的场景：
- 生产者快于消费者 → 用pdTRUE批量消费
- 一对一精确同步 → Notification是最佳选择
- 需要多个task同时等待同一个事件 → 还是用队列或事件组吧
另外，Notification还有一个骚操作——直接传32位数据。
// 发送时还能带个值过去 xTaskNotify(xTaskHandle, 0x12345678, eSetValueWithOverwrite); // 接收端 uint32_t value; xTaskNotifyWait(0, ULONG_MAX, &value, portMAX_DELAY); // value == 0x12345678这就不是信号量能干的事了。等于说Notification把"同步"和"传一个整数"这两个事合并了。有些简单的状态机通知场景，一个Notification搞定，省掉一个队列的开销。
之前看到有人问：有了Notification，是不是就不用学信号量了？
我觉得不是。这俩是不同维度的工具。Notification胜在轻量和速度，适合高频、一对一的场景；信号量适合需要独立同步对象、多对多拓扑、以及需要明确的release-acquire语义的地方。FreeRTOS文档里自己都说了，Notification的主要限制就是"each task can only have one notification state"。
最后放一个我常用的写法，生产者和消费者之间传一个简单的阈值状态：
void vSensorTask(void *pvParameters) { uint32_t reading; for(;;) { reading = read_sensor(); if(reading > THRESHOLD_HIGH) { // 带数据通知——告诉处理任务具体读数 xTaskNotify(vProcessTask, reading, eSetValueWithOverwrite); } else if(reading < THRESHOLD_LOW) { xTaskNotify(vProcessTask, 0, eSetValueWithOverwrite); } vTaskDelay(pdMS_TO_TICKS(50)); } } void vProcessTask(void *pvParameters) { uint32_t value; BaseType_t ret; for(;;) { ret = xTaskNotifyWait(0x00, 0xFFFFFFFF, &value, pdMS_TO_TICKS(100)); if(ret == pdPASS) { if(value == 0) { enter_low_power_mode(); } else { handle_high_reading(value); } } } }说实话，以前总觉得FreeRTOS这么小一个内核，功能肯定不够用。但用久了才发现，它那些看起来不起眼的小特性，很多才是真正干活的东西。Notification就是典型——API就几个函数，文档也就几页，但用好了能把代码写得又轻又干净。
