關(guān)注、星標公眾號，直達精彩內(nèi)容

ID：技術(shù)讓夢想更偉大

整理：李肖遙

在FreeRTOS版本V8.2.0中推出了全新的功能：任務(wù)通知。

在大多數(shù)情況下，任務(wù)通知可以替代二進制信號量、計數(shù)信號量、事件組，可以替代長度為1的隊列（可以保存一個32位整數(shù)或指針值），并且任務(wù)通知速度更快、使用的RAM更少！

我在《 FreeRTOS系列第14篇---FreeRTOS任務(wù)通知》一文中介紹了任務(wù)通知如何使用以及局限性，今天我們將分析任務(wù)通知的實現(xiàn)源碼，看一下任務(wù)通知是如何做到效率與RAM消耗雙贏的。

在《FreeRTOS高級篇6---FreeRTOS信號量分析》一文中我們已經(jīng)知道，F(xiàn)reeRTOS的信號量是使用隊列機制實現(xiàn)的，數(shù)據(jù)結(jié)構(gòu)也完全是隊列的那一套。

而任務(wù)通知則不同，它的數(shù)據(jù)結(jié)構(gòu)嵌在任務(wù)TCB（任務(wù)控制塊，見《FreeRTOS高級篇2---FreeRTOS任務(wù)創(chuàng)建分析》）中的，并且數(shù)據(jù)結(jié)構(gòu)十分簡單，涉及到任務(wù)TCB的兩個字段，我們將它單獨列出來：

volatile?uint32_t?ulNotifiedValue;??/*任務(wù)通知值*/??
volatile uint8_t ucNotifyState;?/*任務(wù)通知狀態(tài)，標識任務(wù)是否在等待通知等*/
這兩個字段占用5字節(jié)RAM（本文都是在32位系統(tǒng)下討論），而一個隊列數(shù)據(jù)結(jié)構(gòu)至少占用76字節(jié)RAM！這不是同一數(shù)量級的，所以任務(wù)通知在RAM消耗上完勝。

在分析隊列和信號量的文章中，我們知道在使用隊列、信號量前，必須先創(chuàng)建隊列和信號量，目的是為了創(chuàng)建隊列數(shù)據(jù)結(jié)構(gòu)。

比如使用API函數(shù)xQueueCreate()創(chuàng)建隊列，用API函數(shù)xSemaphoreCreateBinary()創(chuàng)建二進制信號量等等。

再來看任務(wù)通知，由于任務(wù)通知的數(shù)據(jù)結(jié)構(gòu)包含在任務(wù)TCB中，只要任務(wù)存在，任務(wù)通知數(shù)據(jù)結(jié)構(gòu)就已經(jīng)創(chuàng)建完畢，可以直接使用！在易用性上，任務(wù)通知再次獲勝。

要想了解任務(wù)通知在性能上占優(yōu)的原因，就要分析源代碼了。

只有任務(wù)可以等待通知，中斷服務(wù)函數(shù)中不可以。

如果等待的通知無效，任務(wù)會進入阻塞狀態(tài)，我們可以將等待通知的任務(wù)看作是消費者；

其它任務(wù)和中斷可以向等待通知的任務(wù)發(fā)送通知，發(fā)送通知的任務(wù)和中斷服務(wù)函數(shù)可以認為是生產(chǎn)者。

處于阻塞的消費者得到通知后會再次進入就緒態(tài)。

任務(wù)通知API函數(shù)主要有兩類，一類發(fā)送通知，一類等待通知。

發(fā)送通知API函數(shù)可以用于任務(wù)和中斷服務(wù)函數(shù)，等待通知API函數(shù)只能用在任務(wù)中。

1.發(fā)送通知

我們先看一下發(fā)送通知API函數(shù)。這類函數(shù)比較多，有6個。

但仔細分析會發(fā)現(xiàn)它們只能完成3種操作，每種操作有兩個API函數(shù)，分別為帶中斷保護版本和不帶中斷保護版本。

FreeRTOS將API細分為帶中斷保護版本和不帶中斷保護版本是為了節(jié)省中斷服務(wù)程序處理時間，提升性能。

和信號量類似，大多數(shù)發(fā)送通知API接口也是由宏實現(xiàn)的，如表1-1所示。

1.1 xTaskGenericNotify()

不帶中斷保護的發(fā)送通知API函數(shù)實際都是調(diào)用函數(shù)xTaskGenericNotify()實現(xiàn)的，我們看一下這個函數(shù)原型：

BaseType_t?xTaskGenericNotify(?
????????TaskHandle_t?xTaskToNotify,?
????????uint32_t?ulValue,?
????????eNotifyAction?eAction,?
????????uint32_t?*pulPreviousNotificationValue?)


• 「xTaskToNotify」：被通知的任務(wù)句柄。
• 「ulValue」：更新的通知值
• 「eAction」：枚舉類型，指明更新通知值的方法，枚舉變量成員以及作用見表1-2所示。
• 「pulPreviousNotifyValue」：回傳未被更新的任務(wù)通知值。如果不需要回傳未被更新的任務(wù)通知值，這里設(shè)置為NULL。

與入隊操作相比較，發(fā)送通知API函數(shù)顯得非常簡單，整理后的源碼如下所示：

BaseType_t?xTaskGenericNotify(?TaskHandle_t?xTaskToNotify,?uint32_t?ulValue,?eNotifyAction?eAction,?uint32_t?*pulPreviousNotificationValue?)
{
TCB_t?*?pxTCB;
BaseType_t?xReturn?=?pdPASS;
uint8_t?ucOriginalNotifyState;
?
?
????configASSERT(?xTaskToNotify?);
????pxTCB?=?(?TCB_t?*?)?xTaskToNotify;
?
?
????taskENTER_CRITICAL();
????{
????????if(?pulPreviousNotificationValue?!=?NULL?)
????????{
???/*?回傳更新前的通知值*/
????????????*pulPreviousNotificationValue?=?pxTCB->ulNotifiedValue;
????????}
?
?
????????ucOriginalNotifyState?=?pxTCB->ucNotifyState;
?
?
????????pxTCB->ucNotifyState?=?taskNOTIFICATION_RECEIVED;
?
?
????????switch(?eAction?)
????????{
????????????case?eSetBits???:
????????????????pxTCB->ulNotifiedValue?|=?ulValue;
????????????????break;
?
?
????????????case?eIncrement?:
????????????????(?pxTCB->ulNotifiedValue?) ;
????????????????break;
?
?
????????????case?eSetValueWithOverwrite?:
????????????????pxTCB->ulNotifiedValue?=?ulValue;
????????????????break;
?
?
????????????case?eSetValueWithoutOverwrite?:
????????????????if(?ucOriginalNotifyState?!=?taskNOTIFICATION_RECEIVED?)
????????????????{
????????????????????pxTCB->ulNotifiedValue?=?ulValue;
????????????????}
????????????????else
????????????????{
????????????????????/*?上次的通知值還未取走,本次通知值丟棄?*/
????????????????????xReturn?=?pdFAIL;
????????????????}
????????????????break;
?
?
????????????case?eNoAction:
????????????????/*?不需要更新通知值*/
????????????????break;
????????}
?
?
????????traceTASK_NOTIFY();
?
?
????????/*?如果被通知的任務(wù)因為等待通知而阻塞,現(xiàn)在將它解除阻塞?*/
????????if(?ucOriginalNotifyState?==?taskWAITING_NOTIFICATION?)
????????{
????????????(?void?)?uxListRemove(?