blog
0%

freertos 队列xQueue分析

发表于 更新于 分类于 Valine：

FreeRTOS提供了多种任务间通讯方式, 包括:

  • 任务通知
  • 队列
  • 二进制信号量
  • 计数信号量
  • 互斥量
  • 递归互斥量

其中, 二进制信号量\计数信号量\互斥量和递归互斥量都是使用Queue 队列来实现的
需要先看下Queue的实现方式
Queue是freertos最重要的任务间通讯方式, 可以在

  • 任务与任务间
  • 中断和任务间传送信息。

发送到队列的消息是通过拷贝实现的，这意味着队列存储的数据是原数据，而不是原数据的引用。先看一下队列的数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
typedef struct QueueDefinition
{
	int8_t *pcHead;					/* 指向队列存储区起始位置*/
	int8_t *pcTail;					/* 指向队列存储区结束后的下一个字节 */
	int8_t *pcWriteTo;				 /* 指向队列存储区的下一个空闲位置 *

	union							/* Use of a union is an exception to the coding standard to ensure two mutually exclusive structure members don't appear simultaneously (wasting RAM). */
	{
		int8_t *pcReadFrom;			/* 当结构体用于队列时,这个字段指向出队项目中的最后一个. */
		UBaseType_t uxRecursiveCallCount;/* 当结构体用于互斥量时,用作计数器,保存递归互斥量被"获取"的次数. */
	} u;

	List_t xTasksWaitingToSend;		/*< List of tasks that are blocked waiting to post onto this queue.  Stored in priority order. */
    								// 等待入Queue而阻塞的任务, 以优先级升序排列*/
	List_t xTasksWaitingToReceive;	// 等待出Queue而阻塞的任务列表, 以优先级升序排列*/

	volatile UBaseType_t uxMessagesWaiting; //当前Queue的队列项数目
	UBaseType_t uxLength;			// 队列项的数目 ? //TODO:
	UBaseType_t uxItemSize;			// 每个队列项的大小

	volatile int8_t cRxLock;		/* Queue上锁后,存储从队列收到的队列项数目(就是队列上锁时从队列中remove出去的队列项数目)，如果队列没有上锁，设置为queueUNLOCKED */
	volatile int8_t cTxLock;		 /* Queue上锁后,存储发送到队列的队列项数目(就是队列上锁时加到该队列的队列项数目)，如果队列没有上锁，设置为queueUNLOCKED */

	#if( ( configSUPPORT_STATIC_ALLOCATION == 1 ) && ( configSUPPORT_DYNAMIC_ALLOCATION == 1 ) )
		uint8_t ucStaticallyAllocated;	
	#endif

} xQUEUE;

初看这个结构, 有好几个意义不是很明确, 比如 xTasksWaitingToSend xTasksWaitingToReceive 是干啥用的, uxMessagesWaiting和uxLength说的是啥, cRxLock``cTxLock表示的是啥意思
都比较懵, 需要结合代码看一下.

队列创建函数 xQueueCreate

真正被执行的函数是xQueueGenericCreate()，通用队列创建函数。 我们来分析一下xQueueGenericCreate()函数，函数原型为：

1
2
#define xQueueCreate( uxQueueLength, uxItemSize ) xQueueGenericCreate( ( uxQueueLength ), ( uxItemSize ), ( queueQUEUE_TYPE_BASE ) )
QueueHandle_t xQueueGenericCreate( const UBaseType_t uxQueueLength, const UBaseType_t uxItemSize, const uint8_t ucQueueType ) PRIVILEGED_FUNCTION;
  • uxQueueLength：队列项数目
  • uxItemSize：每个队列项的大小
  • ucQueueType 类型。可能的值为：
    • queueQUEUE_TYPE_BASE：表示队列
    • queueQUEUE_TYPE_SET：表示队列集合
    • queueQUEUE_TYPE_MUTEX：表示互斥量
    • queueQUEUE_TYPE_COUNTING_SEMAPHORE：表示计数信号量
    • queueQUEUE_TYPE_BINARY_SEMAPHORE：表示二进制信号量
    • queueQUEUE_TYPE_RECURSIVE_MUTEX ：表示递归互斥量

xQueueGenericCreate 函数分析


xQueueGenericReset 队列重置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
BaseType_t xQueueGenericReset( QueueHandle_t xQueue, BaseType_t xNewQueue )
{
    Queue_t * const pxQueue = ( Queue_t * ) xQueue;
    // 进入临界区
    taskENTER_CRITICAL();
    {
        //队列空间的尾部
        pxQueue->pcTail = pxQueue->pcHead + ( pxQueue->uxLength * pxQueue->uxItemSize );
        pxQueue->uxMessagesWaiting = ( UBaseType_t ) 0U;
        //写入数据的起始位置, 没有队列项的话, 就从队列头开始写, 有队列项的话, 从队列项的空间的起始地址写
        pxQueue->pcWriteTo = pxQueue->pcHead;
        //队列的最后一个队列项的起始位置, 注意这里的pcReadFrom 表示的其实是队首, 但是它在存储空间上说是在整个Queue的尾部, 但是入队的时候, 是从高地址往低地址开始写, 也就是从Queue的存储空间的尾部开始插入元素. 叫队首入队
        pxQueue->pcReadFrom = pxQueue->pcHead + ( ( pxQueue->uxLength - ( UBaseType_t ) 1U ) * pxQueue->uxItemSize );
        pxQueue->cRxLock = queueUNLOCKED;
        pxQueue->cTxLock = queueUNLOCKED;

        if( xNewQueue == pdFALSE )
        {   // 这个地方暂时不用管, 因为初始化时 xNewQueue传入的是pdTrue
            if( listLIST_IS_EMPTY( &( pxQueue->xTasksWaitingToSend ) ) == pdFALSE )
            {
                if( xTaskRemoveFromEventList( &( pxQueue->xTasksWaitingToSend ) ) != pdFALSE )
                {
                    queueYIELD_IF_USING_PREEMPTION();
                }
            }
        }
        else
        {
            // 初始化xTasksWaitingToSend xTasksWaitingToReceive列表, 这两个接受的都是任务的事件列表项
            vListInitialise( &( pxQueue->xTasksWaitingToSend  ) );
            vListInitialise( &( pxQueue->xTasksWaitingToReceive ) );
        }
    }
    // 退出临界区
    taskEXIT_CRITICAL();
    return pdPASS;
}

从xQueueGenericCreate 函数中可以看出pcHead pcTail pcWriteTo pcReadFrom uxLength代表的是什么意思, 从xQueueGenericReset 看初始化的意思就能知道

  • pcHead head表示真正存储项的开始, 队列项数目为0时. 表示的是Queue_t 头的起始地址
  • uxLength 队列项的数目
  • uxItemSize 每个队列项占的空间
  • pcWriteTo 写入数据的起始位置, 没有队列项的话, 就从队列头开始写, 有队列项的话, 从队列项空间的起始地址写
  • pcReadFrom 队列的最后一个队列项的起始位置

    WARNING: 一定要注意队列项和列表项是两个名词

    • 队列项是Queue中存储的每个item, item的类型是可以定制的, 每个item的占的空间也是不一样的, 根据定制的类型确定.
    • 列表项专门表示xLIST_ITEM, 前面介绍过这个, 参考下给TCB用的,TCB 有事件列表项, 任务列表项

入队

队列项入队也称为投递（Send），分为带中断保护的入队操作和不带中断保护的入队操作。每种情况下又分为从队列尾部入队和从队列首部入队两种操作
从队列尾部入队还有一种特殊情况，覆盖式(overwrite)入队，即队列满后自动覆盖最旧的队列项。如表所示。
1e18b882-3bac-426e-8018-841c2ec01e62

xQueueGenericSend

这个函数用于入队操作，绝不可以用在中断服务程序中。
根据参数的不同，可以分为:

  • 从队列尾入队
  • 从队列首入队
  • 覆盖式入队。覆盖式入队用于只有一个队列项的场合，入队时如果队列已满，则将之前的队列项覆盖掉。

函数原型为：

1
2
3
4
5
6
7
BaseType_t xQueueGenericSend
( 
    QueueHandle_t xQueue, 
    const void * const pvItemToQueue, 
    TickType_t xTicksToWait, 
    const BaseType_t xCopyPosition 
)

  • xQueue：队列句柄

  • pvItemToQueue：指针，指向要入队(投递)的项目

  • xTicksToWait：如果队列满，等待队列空闲的最大时间，如果队列满并且xTicksToWait被设置成0，函数立刻返回。时间单位为系统节拍时钟周期，

      宏portTICK_PERIOD_MS可以用来辅助计算真实延时值。如果`INCLUDE_vTaskSuspend`设置成1，并且指定延时为`portMAX_DELAY`将引起任务无限阻塞（没有超时）。

  • xCopyPosition：入队位置，可以选择从队列尾入队、从队列首入队和覆盖式入队。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    BaseType_t xQueueGenericSend( QueueHandle_t xQueue, const void * const pvItemToQueue, TickType_t xTicksToWait, const BaseType_t xCopyPosition )
    {
        BaseType_t xEntryTimeSet = pdFALSE, xYieldRequired;
        TimeOut_t xTimeOut;
        Queue_t * const pxQueue = ( Queue_t * ) xQueue;

        // 进入这个函数, 如果调度器是挂起状态时, xTicksToWait 必须是0
    	#if ( ( INCLUDE_xTaskGetSchedulerState == 1 ) || ( configUSE_TIMERS == 1 ) )
    	{
    		configASSERT( !( ( xTaskGetSchedulerState() == taskSCHEDULER_SUSPENDED ) && ( xTicksToWait != 0 ) ) );
    	}
    	#endif
    	// 为了获得最高效率而放宽了编码标准：有多个返回点
    	for( ;; )
    	{
            // 进入临界区, 关闭tick中断
    		taskENTER_CRITICAL();
    		{
    			// 队列还有空闲?     正在运行的任务一定要比等待访问队列的任务优先级高.
    			// 如果使用覆盖式入队,则不需要关注队列是否满
                1. ---> // 队列未满或者以覆盖式入队的场景
    			if( ( pxQueue->uxMessagesWaiting < pxQueue->uxLength ) || ( xCopyPosition == queueOVERWRITE ) )
    			{
                    //完成数据拷贝工作,分为从队列尾入队,从队列首入队和覆盖式入队, 此处有空闲时, 可以是队列尾入队,从队列首入队和覆盖式入队
                    // 没有空闲时, 则只能是覆盖式入队
    				xYieldRequired = prvCopyDataToQueue( pxQueue, pvItemToQueue, xCopyPosition );
    				... // 省略了 configUSE_QUEUE_SETS 宏打开的情况, 有需求再看, 默认是关闭的				
    				#else /* configUSE_QUEUE_SETS */
    				{
    					/* If there was a task waiting for data to arrive on the
    					queue then unblock it now. */
                        // 是否有任务等待的数据(take)到了, 等到的话就把这个任务解除阻塞
    					if( listLIST_IS_EMPTY( &( pxQueue->xTasksWaitingToReceive ) ) == pdFALSE )
    					{
                            // 本函数send意思就是把要take的数据送过来的意思, 上面的prvCopyDataToQueue 就是送数据过来
                            // 这里是把xTasksWaitingToReceive中的等待事件的任务排在最前面的出队, TCB的事件列表项在调用take这个xQueue的时候会将自己的事件列表项挂到xQueue的xTasksWaitingToReceive列表中, 这个函数做的事情比较多, 需要在后面详细描述 // TODO
    						if( xTaskRemoveFromEventList( &( pxQueue->xTasksWaitingToReceive ) ) != pdFALSE )
    						{
    			// 如果上面排在最前面的任务出队后,加入到readylist中, 同时刷新了最高优先级, 优先级如果比当前正在运行的任务优先级高, 调度到这个任务
    <----						queueYIELD_IF_USING_PREEMPTION();
    						}
    					}
                        // 等待的数据没到, 但是xYieldRequired 是true时, 也可能切换任务, 这个值是prvCopyDataToQueue的返回值,
    					else if( xYieldRequired != pdFALSE )
    					{
    						// 这个支线处理特殊情况, 如果任务take多个mutex, 但是take mutex的顺序与 give mutex的顺序不一致, 也会切换任务? 
    <---					queueYIELD_IF_USING_PREEMPTION();
    					}
    				}
    				#endif /* configUSE_QUEUE_SETS */
    				// 关闭临界区, 打开tick中断, 返回pass
    				taskEXIT_CRITICAL();
    <----			return pdPASS;
    			}
                // 队列满了且不是覆盖式入队的场景
    			else
    			{
                    2.d  ----> // 队列满且不是覆盖式入队且timeout是0, 队列不阻塞任务, 没有timeout的场景, give数据, 立即返回
    				if( xTicksToWait == ( TickType_t ) 0 )
    				{
    					// 关闭临界区, 打开tick中断
    					taskEXIT_CRITICAL();
    <-----			    // 返回队列满
    					return errQUEUE_FULL;
    				}
                    // 设置了timeout, 但是队列又是满的场景
    				else if( xEntryTimeSet == pdFALSE )
    				{
    					// 初始化xTimeOut 结构体
    					vTaskInternalSetTimeOutState( &xTimeOut );
    					xEntryTimeSet = pdTRUE;
    				}
    			}
    		}
            // 关闭
    		taskEXIT_CRITICAL();

            2. ----> // 队列满了又不是覆盖式入队,且又设置了timeout的场景
            // 挂起调度器
    		vTaskSuspendAll();
            // 把Queue上锁
            //  /* 退出临界区,至此,中断和其它任务可以向这个队列执行入队(投递)或出队(读取)操作.
            //  因为队列满,任务无法入队,下面的代码将当前任务将阻塞在这个队列上
            //  在这段代码执行过程中我们需要挂起调度器,防止其它任务操作队列事件列表;
            // 挂起调度器虽然可以禁止其它任务操作这个队列,但并不能阻止中断服务程序操作这个队列,因此还需要将队列上锁
            //    防止中断程序读取队列后,使其它任务解除阻塞,执行上下文切换(因为调度器挂起后,不允许执行上下文切换) */
    		prvLockQueue( pxQueue );

    		/* 查看任务的超时时间是否到期 */ 
            // 任务超时时间未到期
    		if( xTaskCheckForTimeOut( &xTimeOut, &xTicksToWait ) == pdFALSE )
    		{
                2.b ------> // 队列满了, 阻塞时间未到期
    			if( prvIsQueueFull( pxQueue ) != pdFALSE )
    			{
                    // 队列满了, 将give 数据(信号量)的任务挂到Queue的xTasksWaitingToSend列表下
    				vTaskPlaceOnEventList( &( pxQueue->xTasksWaitingToSend ), xTicksToWait );

    				// * 解除队列锁,如果有任务要解除阻塞,则将任务移到pending ready list中(因为当前调度器挂起,所以不能移到ready list)*/
    				prvUnlockQueue( pxQueue );
    				// 恢复调度器,将挂起就绪列表中的任务移到就绪列表中, 返回值是xAlreadyYielded, 已经切换过任务的意思, 如果没有pending ready list的话, 返回false, 那这个任务就需要主动切换到下一个优先级最高的ready的任务.
                    // 往Queue中投递数据的这个任务成功阻塞在等待入队操作后，这个任务(当前正在运行)就没有必要再占用CPU了，所以接下来解除队列锁、恢复调度器、进行任务切换，下一个处于最高优先级的就绪任务就会被运行了。
                    // 这意思大概就是无论怎么样都要触发下pendsv, 切换到下一个任务, 注意此时这个任务已经由上面 vTaskPlaceOnEventList 的调用, 任务状态从就绪态转移到阻塞态(延时态)了, 没有其他任务的话, 也会切到idle上.
    				if( xTaskResumeAll() == pdFALSE )
    				{
    					portYIELD_WITHIN_API();
    				}
    			}
                2.c -------> // 未到期, 队列未满, 重试, 这个地方是double check? 怎么又变成队列未满了, 上面已经检查过一遍队列是满的才会走下来
                    // (prvIsQueueFull 就是 pxQueue->uxMessagesWaiting == pxQueue->uxLength)的意思, 走到这表示 pxQueue->uxMessagesWaiting < pxQueue->uxLength
    			else
    			{
    				/* Try again. */
    				prvUnlockQueue( pxQueue );
    				( void ) xTaskResumeAll();
    			}
    		}
            2.a ----> // 任务超时时间到期了 xTaskCheckForTimeOut返回true
    		else
    		{
    			// 解除队列锁定
    			prvUnlockQueue( pxQueue );
                // 恢复调度器, 同时将pending ready list中的任务挪到 ready list中
    			( void ) xTaskResumeAll();
    			// 返回 errQUEUE_FULL
    <----		return errQUEUE_FULL;
    		}
    	} // end of for !!!!
    }

prvCopyDataToQueue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
static BaseType_t prvCopyDataToQueue( Queue_t * const pxQueue, const void *pvItemToQueue, const BaseType_t xPosition )
{
    BaseType_t xReturn = pdFALSE;
    UBaseType_t uxMessagesWaiting;
	uxMessagesWaiting = pxQueue->uxMessagesWaiting;
	// 每个队列项占的空间是0的话, 比如二进制信号量/计数信号量/互斥量, 不需要额外做别的操作, 直接把uxMessagesWaiting+1 即可
	if( pxQueue->uxItemSize == ( UBaseType_t ) 0 )
	{
		#if ( configUSE_MUTEXES == 1 )
		{
			if( pxQueue->uxQueueType == queueQUEUE_IS_MUTEX )
			{
				// 这里是投递来了mutex, 因为mutex和二进制信号量还有计数信号量不一样, mutex 是成对调用的, 一个Queue被take后, 只能被该task give(release), 其他task才能take到. 
                // 因此需要pxMutexHolder字段记录持有者, 这里是give, 说明现在mutex是无主的了, 别的task可以take了.
                // 这里还有处理优先级继承的逻辑, 持有该mutex的任务的现在释放mutex了, 优先级需要归位
				xReturn = xTaskPriorityDisinherit( ( void * ) pxQueue->pxMutexHolder );
                // pxMutexHolder 就是 pcTail
				pxQueue->pxMutexHolder = NULL;
			}
		}
		#endif /* configUSE_MUTEXES */
	}
    // 有队列项存储空间的话, 拷贝到队尾, 如果是第一个item的话, 起始是从队列项空间的起始地址开始写, 再往后的话, 就是每次+uxItemSize
	else if( xPosition == queueSEND_TO_BACK )
	{
        // 将传递的数据拷贝到Queue的空间了
		( void ) memcpy( ( void * ) pxQueue->pcWriteTo, pvItemToQueue, ( size_t ) pxQueue->uxItemSize );
        // 如果是第一个item的话, 起始是从队列项空间的起始地址开始写, 再往后的话, 就是每次+uxItemSize
		pxQueue->pcWriteTo += pxQueue->uxItemSize;
		if( pxQueue->pcWriteTo >= pxQueue->pcTail )
		{
			pxQueue->pcWriteTo = pxQueue->pcHead;
		}
	}
    // 有队列项存储空间, 拷贝到队首, 如果是第一个item的话, 起始是从队列项空间的尾部地址减去一个uxItemSize(保证有空间能刚好放下这个item,写完后这个item的尾巴地址正好是队列项存储空间的尾巴地址), 再往后的话, 就是每次-uxItemSize
	else
	{
        // 将传递的数据拷贝到Queue的空间了
		( void ) memcpy( ( void * ) pxQueue->u.pcReadFrom, pvItemToQueue, ( size_t ) pxQueue->uxItemSize ); 
		pxQueue->u.pcReadFrom -= pxQueue->uxItemSize;
		if( pxQueue->u.pcReadFrom < pxQueue->pcHead ) 
		{
			pxQueue->u.pcReadFrom = ( pxQueue->pcTail - pxQueue->uxItemSize );
		}
		// 覆盖写入时, 队列项只有1个, 覆盖它, 所以uxMessagesWaiting 不变.
		if( xPosition == queueOVERWRITE )
		{
			if( uxMessagesWaiting > ( UBaseType_t ) 0 )
			{
				--uxMessagesWaiting;
			}
		}
	}
	pxQueue->uxMessagesWaiting = uxMessagesWaiting + ( UBaseType_t ) 1;
	return xReturn;
}

prvCopyDataToQueue 小结

这个函数处理三种入队情况，

  - 第一种是队列项大小为0时（即队列结构体成员uxItemSize为0，比如二进制信号量和计数信号量 互斥量），不进行数据拷贝工作，而是将队列项计数器加1（即队列结构体成员uxMessagesWaiting++）；
     - 注意mutex类型的要进行特殊处理,优先级归位, 有主的mutex变成无主的
  - 第二种情况是从队列尾入队时，则将数据拷贝到指针pxQueue->pcWriteTo指向的地方、更新指针指向的位置、队列项计数器加1；
  - 第三种情况是从队列首入队时，则将数据拷贝到指针pxQueue->pcReadFrom指向的地方、更新指针指向的位置、队列项计数器加1。如果是覆盖式入队，还会调整队列项计数器的值。

多核上的思考

多个cpu时需要额外考虑什么?
Queue 只有一个

  • 如果有队列项, 队列项会被拷贝到Queue的队列项空间中.
  • 没有队列项吗, 那使用的数据只有Queue结构体本身的数据, 最重要的就是uxMessagesWaiting的同步.

因此多cpu时, 肯定要额外的锁(spinlock?), Queue是作为共享资源被访问. 多个cpu不能在同一时刻改写Queue中的数据. 需要保证Queue在多个cpu上的同步状态.

xQueueGenericSend 小结

  1. 当任务将数据入队时，如果队列未满或者以覆盖式入队，情况是最简单的:

a. 调用函数prvCopyDataToQueue()将要入队的数据拷贝到队列。
这个函数处理三种入队情况，

  - 第一种是队列项大小为0时（即队列结构体成员uxItemSize为0，比如二进制信号量和计数信号量 互斥量），不进行数据拷贝工作，而是将队列项计数器加1（即队列结构体成员uxMessagesWaiting++）；
  - 第二种情况是从队列尾入队时，则将数据拷贝到指针pxQueue->pcWriteTo指向的地方、更新指针指向的位置、队列项计数器加1；
  - 第三种情况是从队列首入队时，则将数据拷贝到指针pxQueue->pcReadFrom指向的地方、更新指针指向的位置、队列项计数器加1。如果是覆盖式入队，还会调整队列项计数器的值。

b. 完成数据入队操作后，还要检查是否有任务因为等待出队而阻塞, 把xTasksWaitingToReceive中的等待事件的任务排在最前面的出队 (任务TCB的事件列表项在调用take这个xQueue的时候会将自己的事件列表项挂到xQueue的xTasksWaitingToReceive列表中)
如果上面排在最前面的任务出队后,加入到readylist中, 同时刷新了最高优先级, 优先级如果比当前正在运行的任务优先级高, 调度到这个任务
因等待出队而阻塞的任务会将任务的事件列表挂接到Queue的xTasksWaitingToReceive上 . 现在，因为要解除任务阻塞，我们需要将任务的事件列表项从队列的等待出队队列上删除，并且将任务移动到就绪列表中。这一切，都是调用函数xTaskRemoveFromEventList()实现的。
      之后，如果解除阻塞的任务优先级比当前任务优先级更高，则触发一个PendSV中断，等退出临界区后，进行上下文切换。入队任务完成

  1. 上面讨论了最理想的情况，过程也简洁明了，但如果任务入队时，队列满并且不允许覆盖入队，则情况会变得复杂起来。

先看一个简单分支：
a. 阻塞时间为0的情况。设置阻塞时间为0意味着当队列满时，函数立即返回，返回一个错误代码，表示队列满。
b. 如果阻塞时间不为0，则本任务会因为等待入队而进入阻塞。在将任务设置为阻塞的过程中，是不希望有其它任务和中断操作这个队列的事件列表的（队列结构体成员xTasksWaitingToReceive列表和xTasksWaitingToSend列表)

  • 因为操作队列事件列表可能引起其它任务解除阻塞，这可能会发生优先级翻转。

比如任务A的优先级低于本任务，但是在本任务进入阻塞的过程中，任务A却因为其它原因解除阻塞了，这显然是要绝对禁止的。

  • 因此FreeRTOS使用挂起调度器来简单粗暴的禁止其它任务操作队列，因为挂起调度器意味着任务不能切换并且不准调用可能引起任务切换的API函数。

但挂起调度器并不会禁止中断，中断服务函数仍然可以操作队列事件列表，可能会解除任务阻塞、可能会进行上下文切换，这是不允许的。于是，解决办法是不但挂起调度器，还要给队列上锁！

  • 队列结构体中有两个成员跟队列上锁有关：cRxLock和cTxLock。这两个成员变量为queueUNLOCKED（宏，定义为-1）时，表示队列未上锁；当这两个成员变量为queueLOCKED_UNMODIFIED（宏，定义为0）时，表示队列上锁。

给队列上锁是调用宏prvLockQueue()实现的，代码很简单，将队列结构体成员xRxLock和xTxLock都设置为queueLOCKED_UNMODIFIED。
我们看一下给队列上锁是如何起作用的。

     - 当中断服务程序操作队列并且导致阻塞的任务解除阻塞时，会首先判断该队列是否上锁，
        - 如果没有上锁，则解除被阻塞的任务，还会根据需要设置上下文切换请求标志；
        - 如果队列已经上锁，则不会解除被阻塞的任务，取而代之的是，将cRxLock或cTxLock加1，表示队列上锁期间入队(往Queue中投递数据, 比如give 信号量)或出队(从Queue中取数据, 消费者, 比如take信号量)的数目，也表示有任务可以解除阻塞了。

有将队列上锁操作，就会有解除队列锁操作。函数prvUnlockQueue()用于解除队列锁，将可以解除阻塞的任务插入到就绪列表，解除任务的最大数量由xRxLock和xTxLock指定

  • 经过一系列的逻辑判断，发现本任务还是要进入阻塞状态，则调用函数vTaskPlaceOnEventList()来实现。这个函数将揭示任务因等待特定事件而进入阻塞的详细步骤，其实非常简单，

只有两步：

     - 第一步，将任务的事件列表项（任务TCB结构体成员xEventListItem）插入到队列的等待入队列表（队列结构体成员`xTasksWaitingToSend`）中；
     - 第二步，将任务的状态列表项（任务TCB结构体成员xStateListItem）从就绪列表中删除，然后插入到延时列表中(就绪态->阻塞态)，任务的最大延时时间放入xStateListItem. xItemValue中，每次系统节拍定时器中断服务函数中，都会检查这个值，检测任务是否超时。
  • 当任务成功阻塞在等待入队操作后，当前任务就没有必要再占用CPU了，所以接下来解除队列锁、恢复调度器、进行任务切换，下一个处于最高优先级的就绪任务就会被运行了。(该任务从就绪态转换到阻塞态), 即使没有其他就绪态的任务, 也会切到idle上.
  1. 对于这个函数, 还有个问题, 为什么主逻辑用for循环包起来, 这个主要是为了考虑第2个场景, 假设队列满且非覆盖式且设置了timeout的场景, 任务会从就绪态转到阻塞态去, 考虑最简单的情况, 任务timeout到期了, 这个任务会被切回来, 是不是还要再来一遍检查, 此时再来一遍那这个任务到期了, 走2.a分支出去了

这个地方有点绕,为什么不直接在回来时返回出去呢?


0d2d3e2c-d00f-4607-8276-4580b30e7bc1

xQueueGenericSendFromISR

中断上下文使用的send(ISR 就是中断上下文的意思)
这个函数用于入队，用于中断服务程序中。根据参数的不同，可以从队列尾入队、从队列首入队也可以覆盖式入队。覆盖式入队用于只有一个队列项的场合，入队时如果队列已满，则将之前的队列项覆盖掉。
函数原型为：

1
BaseType_t xQueueGenericSendFromISR( QueueHandle_t xQueue, const void * const pvItemToQueue, BaseType_t * const pxHigherPriorityTaskWoken, const BaseType_t xCopyPosition )
  • xQueue：队列句柄。
  • pvItemToQueue：指针，指向要入队的项目。
  • pxHigherPriorityTaskWoken：
    • 如果入队导致一个任务解锁，并且解锁的任务优先级高于当前运行的任务，则该函数将*pxHigherPriorityTaskWoken设置成pdTRUE。
    • 如果xQueueSendFromISR()设置这个值为pdTRUE，则中断退出前需要一次上下文切换。
    • 从FreeRTOS V7.3.0起，pxHigherPriorityTaskWoken称为一个可选参数，并可以设置为NULL。
  • xCopyPosition：入队位置，可以选择从队列尾入队、从队列首入队和覆盖式入队。

这个函数和xQueueGenericSend()很相似，但是当队列满时不会阻塞，直接返回一个错误码，表示队列满（相当于阻塞时间为0）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
BaseType_t xQueueGenericSendFromISR( QueueHandle_t xQueue, const void * const pvItemToQueue, BaseType_t * const pxHigherPriorityTaskWoken, const BaseType_t xCopyPosition )
{
    BaseType_t xReturn;
    UBaseType_t uxSavedInterruptStatus;
    Queue_t * const pxQueue = ( Queue_t * ) xQueue;
    //balabala, 支持中断嵌套的系统需要配置这个, 一堆解释, 后面有需要再看, mips不支持中断嵌套
	portASSERT_IF_INTERRUPT_PRIORITY_INVALID();
    // 暂存status mask 中断状态
	uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
	{
        1.  ---> //  队列未满或者是覆盖式入队的场景
		if( ( pxQueue->uxMessagesWaiting < pxQueue->uxLength ) || ( xCopyPosition == queueOVERWRITE ) )
		{
			const int8_t cTxLock = pxQueue->cTxLock;
            //  /*完成数据拷贝工作,分为从队列尾入队,从队列首入队和覆盖式入队*/
			( void ) prvCopyDataToQueue( pxQueue, pvItemToQueue, xCopyPosition );
			 1.a ----> // 队列未上锁, 解除被阻塞的任务，还会根据需要设置上下文切换请求标志
			if( cTxLock == queueUNLOCKED )
			{
				...// 省略配置了configUSE_QUEUE_SETS的情况
				#else /* configUSE_QUEUE_SETS */
				{
					if( listLIST_IS_EMPTY( &( pxQueue->xTasksWaitingToReceive ) ) == pdFALSE )
					{
						if( xTaskRemoveFromEventList( &( pxQueue->xTasksWaitingToReceive ) ) != pdFALSE )
						{
							/* 解除阻塞的任务优先级比当前任务高,记录上下文切换请求,等返回中断服务程序后,可以显式的强制上下文切换 */
							if( pxHigherPriorityTaskWoken != NULL )
							{
								*pxHigherPriorityTaskWoken = pdTRUE;
							}
						}
					}
				}
				#endif /* configUSE_QUEUE_SETS */
			}
            1.b ----> /* 队列上锁,则队列事件列表不能被改变.  增加锁计数器
                         等到任务解除队列锁时,使用这个计数器就可以知道有多少数据入队,可以最多解除多少个因等待从队列读数据而阻塞的任务 */
			else
			{
				pxQueue->cTxLock = ( int8_t ) ( cTxLock + 1 );
			}
			xReturn = pdPASS;
		}
		else
		{
            // 队列满了且不是覆盖式入队的情况, 直接返回error full,
			xReturn = errQUEUE_FULL;
		}
	}
    // 恢复status mask中断状态
	portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );
	return xReturn;
}

因为没有阻塞，所以代码简单了很多，唯一值得注意的是

    1. 当成功入队后，如果有因为等待出队而阻塞(比如take 信号量)的任务，现在可以将其中最高优先级的任务解除阻塞，在执行解除阻塞操作之前，会判断队列是否上锁。

    a. 如果没有上锁，则解除被阻塞的任务，还会根据需要设置上下文切换请求标志；
    b. 如果队列已经上锁，则不会解除被阻塞的任务，取而代之的是将cTxLock加1，表示队列上锁期间入队(即投递)的个数. 在prvUnlockQueue时,会解除等待该信号的任务.

出队(从Queue取数据 消费者)

比如如take信号量:
出队的API函数要相对少一些，也分为带中断保护的出队操作和不带中断保护的出队操作。每种出队情况都可以选择是否删除队列项。
出队API函数:

1467e0d8-b1af-4272-8c9e-17def431dd49

      出队操作和入队操作有很多相似性，将入队流程理解透彻，出队操作不在话下，因此我们不再分析源码。