OpenHarmony——内核对象队列之算法详解（下）

前言

OpenAtom OpenHarmony（以下简称“OpenHarmony”） LiteOS-M 内核是面向 IoT 领域构建的轻量级物联网操作系统内核，具有小体积、低功耗、高性能的特点。在嵌入式领域的开发工作中，无论是自研还是移植系统，均绕不开内核，开发者只有掌握内核的相关知识，才能更好地深耕物联网产品领域。OpenHarmony LiteOS-M内核对象队列的算法包括FIFO和FILO，在上一期发布的《OpenHarmony-内核对象队列之算法详解（上）》文章中，我分享了OpenHarmonyLiteOS-M内核对象队列的FIFO的算法，今天给大家介绍另外一种算法——FILO算法。

关键数据结构

首先关注队列的关键数据结构LosQueueCB，有了这个数据，才能理解队列是如何工作的：

typedef struct {
    UINT8 queue;      /< 消息队列内存区域的指针/
    UINT16 queueState; /*< 消息队列状态 /
    UINT16 queueLen;   /*< 消息队列状态个数 /
    UINT16 queueSize;  /*< 每个消息节点大小 /
    UINT16 queueID;    /*< 消息身份 /
    UINT16 queueHead;  /*< 消息队列的头部/
    UINT16 queueTail;  /*< 消息队列的尾部 /
    UINT16 readWriteableCnt[OS_READWRITE_LEN];  /*< 消息节点循环队列中读或写的消息个数/
    LOS_DL_LIST readWriteList[OS_READWRITE_LEN]; /*< 读或写消息阻塞链表/
    LOS_DL_LIST memList; /*< Pointer to the memory linked list /
  }LosQueueCB;

　　

queue：指向消息节点内存区域，创建队列时按照消息节点个数乘每个节点大小从动态内存池中申请一片空间。

queueState：队列状态，表明队列控制块是否被使用，有OS_QUEUE_INUSED和OS_QUEUE_UNUSED两种状态。

queueLen：消息节点个数，表示该消息队列最大可存储多少个消息。

queueSize：每个消息节点大小，表示队列每个消息可存储信息的大小。

queueID：消息ID，通过它来操作队列。

消息节点按照循环队列的方式访问，队列中的每个节点以数组下标表示，下面的成员与消息节点循环队列有关：

queueHead：循环队列的头部。

queueTail：循环队列的尾部。

readWriteableCnt[OS_QUEUE_WRITE]：消息节点循环队列中可写的消息个数，为0表示循环队列为满，等于queueLen表示循环队列为空。

readWriteableCnt[OS_QUEUE_READ]：消息节点循环队列中可读的消息个数，为0表示循环队列为空，等于queueLen表示消息队列为满。  readWriteList[OS_QUEUE_WRITE]：写消息阻塞链表，链接因消息队列满而无法写入时需要挂起的TASK。

readWriteList[OS_QUEUE_READ]：读消息阻塞链表，链接因消息队列空而无法读取时需要挂起的TASK。

memList：申请内存块阻塞链表，链接因申请某一静态内存池中的内存块失败而需要挂起的TASK。

关键算法

在计算机程序设计中，“先入先出”和“先入后出”都是处理输入数据的方法。上篇文章向大家介绍了FIFO（先入先出）算法，今天给大家讲解FILO（先入后出）算法。一个先入后出(FILO,First In Last Out)的队列，可以形象地理解为手枪的弹匣，装子弹是“入队列”，射击是“出队列”，最先压入弹匣的子弹是最后射出去的。同理，最先入队列的消息也是在最后处理，这就是FILO（先入后出）算法的本质。

1.1FIFO算法之入队列

第一步：队列初始化

下图呈现了一个初始化后的队列：

截取关键函数LOS_QueueCreate，此函数来源于liteos_m内核代码。

LITE_OS_SEC_TEXT_INIT UINT32 LOS_QueueCreate(CHAR *queueName,
                                         UINT16 len,
                                         UINT32 *queueID,
                                         UINT32 flags,
                                         UINT16 maxMsgSize)
{
    LosQueueCB *queueCB = NULL;
    UINT32 intSave;
    LOS_DL_LIST *unusedQueue = NULL;
    UINT8 *queue = NULL;
    UINT16 msgSize;
    ...
    queue = (UINT8 )LOS_MemAlloc(m_aucSysMem0, len  msgSize);
    ...
    queueCB->queueLen = len;
    queueCB->queueSize = msgSize;
    queueCB->queue = queue;
    queueCB->queueState = OS_QUEUE_INUSED;
    queueCB->readWriteableCnt[OS_QUEUE_READ] = 0;
    queueCB->readWriteableCnt[OS_QUEUE_WRITE] = len;
    queueCB->queueHead = 0;
    queueCB->queueTail = 0;
    LOS_ListInit(&queueCB->readWriteList[OS_QUEUE_READ]);
    LOS_ListInit(&queueCB->readWriteList[OS_QUEUE_WRITE]);
    LOS_ListInit(&queueCB->memList);
    LOS_IntRestore(intSave);

    *queueID = queueCB->queueID;

    OsHookCall(LOS_HOOK_TYPE_QUEUE_CREATE, queueCB);

    return

　　

queue指针指向队列的内存，队列分配了len个消息，每个消息的大小为msgSize。与此同时头指针和尾指针的初始化为0，意味着队列为空，还没有消息入队列。

第二步：第一个消息入队列

各类任务可以作为队列的生产者，队列初始化后，任务可以放置第一个消息，在此选择FILO的方式来放置消息。

下图是FIFO插入第一个数据后的内存形态：

FILO的操作包含在OsQueueBufferOperate函数中，这次是进入OS_QUEUE_WRITE_HEAD的分支处理：

static INLINE VOID OsQueueBufferOperate(LosQueueCB *queueCB, UINT32 operateType,
                                                            VOID bufferAddr, UINT32 bufferSize)
{
    UINT8 *queueNode = NULL;
    UINT32 msgDataSize;
    UINT16 queuePosition;
    errno_t rc;

    / get the queue position /
    switch (OS_QUEUE_OPERATE_GET(operateType)) {
        case OS_QUEUE_READ_HEAD:
            queuePosition = queueCB->queueHead;
            ((queueCB->queueHead + 1) == queueCB->queueLen) ? (queueCB->queueHead = 0) : (queueCB->queueHead++);
            break;

        case OS_QUEUE_WRITE_HEAD:
            (queueCB->queueHead == 0) ? (queueCB->queueHead = (queueCB->queueLen - 1)) : (--queueCB->queueHead);
            queuePosition = queueCB->queueHead;
            break;

        case OS_QUEUE_WRITE_TAIL:
            queuePosition = queueCB->queueTail;
            ((queueCB->queueTail + 1) == queueCB->queueLen) ? (queueCB->queueTail = 0) : (queueCB->queueTail++);
            break;
    ...
}

　　

OsQueueBufferOperate是队列内存的核心操作函数，FILO算法的本质是往队列的头部添加数据，入队列的操作抽象为OS_QUEUE_WRITE_HEAD操作。而本次操作和FIFO不一样，插入数据不再移动tail这个“尾巴”指针，后续无论是入队列操作还是出队列操作，tail指针都不会被操作。

第三步：继续生产数据

数据继续生产，第2个消息进入队列后继续移动head指针，如下图所示：

第三个消息也是重复的移动head指针，如下图所示：

第四步：生产数据结束

本次实例以生产者生产四个消息为结束点，最后形态的队列下图所示：

1.2 FIFO算法之出队列

第一步：取出队列头消息。由于这是先入后出的算法，因此第一个出队列的消息是最后入队列的，也就是队列中标注为“第4个”的消息。

消费后的消息空间也是unused空间，在此处用其它颜色标注消费后的消息，便于读者理解队列的变化情况。

回顾一下OsQueueBufferOperate函数的关键代码，这一次是读的分支：

/ get the queue position /
switch (OS_QUEUE_OPERATE_GET(operateType)) {
    case OS_QUEUE_READ_HEAD:
        queuePosition = queueCB->queueHead;
        ((queueCB->queueHead + 1) == queueCB->queueLen) ? (queueCB->queueHead = 0) : (queueCB->queueHead++);
        break;

　　

queueHead是头指针，它的移动代表着出队列的行为，queueHead目前指向“第4个”消息，往后移动一个，应用得到“第4个”消息的返回值。此处可见，最后入队列的消息最先出。

第二步：继续消费

第三个消息被消费的图示：

第二个消息被消费的图示：

第三步：消费完毕

最后一个消息也处理完成，于是head指针和tail指针均移动到下图的位置。队列为空，任务结束。

这时如果把图重新换个方向来看，那么就很容易了解这个算法的本质。Tail指针全程没有用到，如果把它去掉，水平方向的队列改为垂直方向。如下图所示，可见该图片为典型的入栈操作。由此可知，OpenHarmony内核通过头指针的写操作和读操作，把栈的操作兼容到队列中。

总结

本文主要介绍了OpenHarmony内核对象队列的算法之FILO，至此，队列的2个算法都已介绍完毕。通过对FIFO和FILO这2个算法的详解，开发者能够更加全面了解OpenHarmony LiteOS-M 内核队列算法，以便将来在内核开发工作中遇到队列的其他算法，也能够举一反三，迅速掌握。