FreeRTOS系列第26篇---FreeRTOS任务通知分析

关注、星标公众号，直达精彩内容

ID：技术让梦想更伟大

整理：李肖遥

在FreeRTOS版本V8.2.0中推出了全新的功能：任务通知。

在大多数情况下，任务通知可以替代二进制信号量、计数信号量、事件组，可以替代长度为1的队列（可以保存一个32位整数或指针值），并且任务通知速度更快、使用的RAM更少！

我在《 FreeRTOS系列第14篇---FreeRTOS任务通知》一文中介绍了任务通知如何使用以及局限性，今天我们将分析任务通知的实现源码，看一下任务通知是如何做到效率与RAM消耗双赢的。

在《FreeRTOS高级篇6---FreeRTOS信号量分析》一文中我们已经知道，FreeRTOS的信号量是使用队列机制实现的，数据结构也完全是队列的那一套。

而任务通知则不同，它的数据结构嵌在任务TCB（任务控制块，见《FreeRTOS高级篇2---FreeRTOS任务创建分析》）中的，并且数据结构十分简单，涉及到任务TCB的两个字段，我们将它单独列出来：

volatile uint32_t ulNotifiedValue;  /*任务通知值*/  
volatile uint8_t ucNotifyState; /*任务通知状态，标识任务是否在等待通知等*/
这两个字段占用5字节RAM（本文都是在32位系统下讨论），而一个队列数据结构至少占用76字节RAM！这不是同一数量级的，所以任务通知在RAM消耗上完胜。

在分析队列和信号量的文章中，我们知道在使用队列、信号量前，必须先创建队列和信号量，目的是为了创建队列数据结构。

比如使用API函数xQueueCreate()创建队列，用API函数xSemaphoreCreateBinary()创建二进制信号量等等。

再来看任务通知，由于任务通知的数据结构包含在任务TCB中，只要任务存在，任务通知数据结构就已经创建完毕，可以直接使用！在易用性上，任务通知再次获胜。

要想了解任务通知在性能上占优的原因，就要分析源代码了。

只有任务可以等待通知，中断服务函数中不可以。

如果等待的通知无效，任务会进入阻塞状态，我们可以将等待通知的任务看作是消费者；

其它任务和中断可以向等待通知的任务发送通知，发送通知的任务和中断服务函数可以认为是生产者。

处于阻塞的消费者得到通知后会再次进入就绪态。

任务通知API函数主要有两类，一类发送通知，一类等待通知。

发送通知API函数可以用于任务和中断服务函数，等待通知API函数只能用在任务中。

1.发送通知

我们先看一下发送通知API函数。这类函数比较多，有6个。

但仔细分析会发现它们只能完成3种操作，每种操作有两个API函数，分别为带中断保护版本和不带中断保护版本。

FreeRTOS将API细分为带中断保护版本和不带中断保护版本是为了节省中断服务程序处理时间，提升性能。

和信号量类似，大多数发送通知API接口也是由宏实现的，如表1-1所示。

1.1 xTaskGenericNotify()

不带中断保护的发送通知API函数实际都是调用函数xTaskGenericNotify()实现的，我们看一下这个函数原型：

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


• 「xTaskToNotify」：被通知的任务句柄。
• 「ulValue」：更新的通知值
• 「eAction」：枚举类型，指明更新通知值的方法，枚举变量成员以及作用见表1-2所示。
• 「pulPreviousNotifyValue」：回传未被更新的任务通知值。如果不需要回传未被更新的任务通知值，这里设置为NULL。

与入队操作相比较，发送通知API函数显得非常简单，整理后的源码如下所示：

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();
 
 
        /* 如果被通知的任务因为等待通知而阻塞,现在将它解除阻塞 */
        if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
        {
            ( void ) uxListRemove(