鸿蒙源码分析（七十一）

最后还是想说一下消息队列

基本概念

消息队列，是一种常用于任务间通信的数据结构。队列接收来自任务或中断的不固定长度消息，并根据不同的接口确定传递的消息是否存放在队列空间中。
任务能够从队列里面读取消息，当队列中的消息为空时，挂起读取任务；当队列中有新消息时，挂起的读取任务被唤醒并处理新消息。任务也能够往队列里写入消息，当队列已经写满消息时，挂起写入任务；当队列中有空闲消息节点时，挂起的写入任务被唤醒并写入消息。如果将读队列和写队列的超时时间设置为0，则不会挂起任务，接口会直接返回，这就是非阻塞模式。
消息队列提供了异步处理机制，允许将一个消息放入队列，但不立即处理。同时队列还有缓冲消息的作用。
队列用于任务间通信，可以实现消息的异步处理。同时消息的发送方和接收方不需要彼此联系，两者间是解耦的

队列代码：
这一份代码是开源中国网的已有注释，我们可以看到这里的消息队列的各个属性，根据英文单词就能明白作用（个人觉得甚至不用注释了）

typedef struct {
    
    
    UINT8 *queueHandle; /**< Pointer to a queue handle */	//指向队列句柄的指针
    UINT16 queueState; /**< Queue state */	//队列状态
    UINT16 queueLen; /**< Queue length */	//队列中消息总数的上限值，由创建时确定，不再改变
    UINT16 queueSize; /**< Node size */		//消息节点大小，由创建时确定，不再改变，即定义了每个消息长度的上限.
    UINT32 queueID; /**< queueID */			//队列ID
    UINT16 queueHead; /**< Node head */		//消息头节点位置（数组下标）
    UINT16 queueTail; /**< Node tail */		//消息尾节点位置（数组下标）
    UINT16 readWriteableCnt[OS_QUEUE_N_RW]; /**< Count of readable or writable resources， 0:readable， 1:writable */
											//队列中可写或可读消息数，0表示可读，1表示可写
    LOS_DL_LIST readWriteList[OS_QUEUE_N_RW]; /**< the linked list to be read or written， 0:readlist， 1:writelist */
											//挂的都是等待读/写消息的任务链表，0表示读消息的链表，1表示写消息的任务链表
    LOS_DL_LIST memList; /**< Pointer to the memory linked list */	//@note_why 这里尚未搞明白是啥意思 ，是共享内存吗？
} LosQueueCB;//读写队列分离

这里有两个lite版本的宏定义变量

LITE_OS_SEC_BSS LosQueueCB *g_allQueue = NULL;//消息队列池
LITE_OS_SEC_BSS STATIC LOS_DL_LIST g_freeQueueList;//空闲队列链表，管分配的，需要队列从这里申请

这里是两个链表和队列池，我们可以发现链表经常使用。
以上为队列的样子，具体的使用也是参考别人的代码，但是这部分代码确实相比其他代码更吸引我。
一些引用的解读：

和进程，线程，定时器一样，消息队列也由全局统一的消息队列池管理，池有多大?默认是1024
鸿蒙内核对消息的总个数有限制，queueLen消息总数的上限，在创建队列的时候需指定，不能更改.
对每个消息的长度也有限制， queueSize 规定了消息的大小，也是在创建的时候指定.
为啥要指定总个数和每个的总大小，是因为内核一次性会把队列的总内存(queueLen*queueSize)申请下来，确保不会出现后续使用过程中内存不够的问题出现，但同时也带来了内存的浪费，因为很可能大部分时间队列并没有跑满.
队列的读取由queueHead，queueTail管理，Head表示队列中被占用的消息节点的起始位置。Tail表示被占用的消息节点的结束位置，也是空闲消息节点的起始位置。队列刚创建时，Head和Tail均指向队列起始位置
写队列时，根据readWriteableCnt[1]判断队列是否可以写入，不能对已满（readWriteableCnt[1]为0）队列进行写操作。写队列支持两种写入方式：向队列尾节点写入，也可以向队列头节点写入。尾节点写入时，根据Tail找到起始空闲消息节点作为数据写入对象，如果Tail已经指向队列尾部则采用回卷方式。头节点写入时，将Head的前一个节点作为数据写入对象，如果Head指向队列起始位置则采用回卷方式。
读队列时，根据readWriteableCnt[0]判断队列是否有消息需要读取，对全部空闲（readWriteableCnt[0]为0）队列进行读操作会引起任务挂起。如果队列可以读取消息，则根据Head找到最先写入队列的消息节点进行读取。如果Head已经指向队列尾部则采用回卷方式。
删除队列时，根据队列ID找到对应队列，把队列状态置为未使用，把队列控制块置为初始状态。如果是通过系统动态申请内存方式创建的队列，还会释放队列所占内存。
留意readWriteList，这又是两个双向链表，双向链表是内核最重要的结构体，牢牢的寄生在宿主结构体上.readWriteList上挂的是未来读/写消息队列的任务列表.

队列有啥特点呢：

消息以先进先出的方式排队，支持异步读写。
读队列和写队列都支持超时机制。
每读取一条消息，就会将该消息节点设置为空闲。
发送消息类型由通信双方约定，可以允许不同长度（不超过队列的消息节点大小）的消息。
一个任务能够从任意一个消息队列接收和发送消息。
多个任务能够从同一个消息队列接收和发送消息。
创建队列时所需的队列空间，默认支持接口内系统自行动态申请内存的方式，同时也支持将用户分配的队列空间作为接口入参传入的方式。

关于队列的相关前提操作

我们首先是要创建，创建之后初始化后才可以投入正常使用。我们知道没一个队列都有一个id，这个是唯一指定的标识符，还有对应的操作码：指明本次操作是读还是写。
初始化时侯主要是对全局变量进行赋值，创建一个消息队列池。timeout只用于当队列中没有读/写内容时的等待，这里的消息队列和任务链表出现频率很高，不只是队列。

LITE_OS_SEC_TEXT_INIT UINT32 OsQueueInit(VOID)//消息队列模块初始化
{
    
    
    LosQueueCB *queueNode = NULL;
    UINT32 index;
    UINT32 size;

    size = LOSCFG_BASE_IPC_QUEUE_LIMIT * sizeof(LosQueueCB);//支持1024个IPC队列
    /* system resident memory， don't free */
    g_allQueue = (LosQueueCB *)LOS_MemAlloc(m_aucSysMem0， size);//常驻内存
    if (g_allQueue == NULL) {
    
    
        return LOS_ERRNO_QUEUE_NO_MEMORY;
    }
    (VOID)memset_s(g_allQueue， size， 0， size);//清0
    LOS_ListInit(&g_freeQueueList);//初始化空闲链表
    for (index = 0; index < LOSCFG_BASE_IPC_QUEUE_LIMIT; index++) {
    
    //循环初始化每个消息队列
        queueNode = ((LosQueueCB *)g_allQueue) + index;//一个一个来
        queueNode->queueID = index;//这可是 队列的身份证
        LOS_ListTailInsert(&g_freeQueueList， &queueNode->readWriteList[OS_QUEUE_WRITE]);//通过写节点挂到空闲队列链表上
    }//这里要注意是用 readWriteList 挂到 g_freeQueueList链上的，所以要通过 GET_QUEUE_LIST 来找到 LosQueueCB

    if (OsQueueDbgInitHook() != LOS_OK) {
    
    //调试队列使用的.
        return LOS_ERRNO_QUEUE_NO_MEMORY;
    }
    return LOS_OK;
}

调用部分：
在这里插入图片描述

最后的总结

消息队列解决任务间大数据的传递
以一种异步，解耦的方式实现任务通讯
全局由消息队列池统一管理
在创建消息队列时申请内存块存储消息内存.
读/写操作统一管理，分开执行，A任务 读/写完消息后会立即唤醒等待写/读的B任务.