OpenHarmony——内核IPC机制数据结构解析

一、前言​

OpenAtom OpenHarmony（以下简称“OpenHarmony”）是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代，基于开源的方式，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。

作为面向全场景、全连接、全智能的分布式泛终端操作系统，OpenHarmony通过将各类不同终端设备的能力进行整合，实现硬件互助、资源共享，为用户提供流畅的全场景体验。为了能适应各种硬件，OpenHarmony提供了LiteOS、Linux内核，并基于这些内核形成了不同的系统类型，同时又在这些系统中构建了一套统一的系统能力。

OpenHarmony LiteOS-M内核是面向IoT领域构建的轻量级物联网操作系统内核，LiteOS-M核为任务间通信提供了多种机制，包括队列、事件、互斥锁和信号量。各机制涉及到哪些关键数据结构？这些数据结构又是如何工作的？接下来我将从队列、事件、互斥锁、信号量几个内核对象出发，为大家讲解内核IPC机制的数据结构。

二、数据结构--队列​

队列又称消息队列，是一种常用于任务间通信的数据结构，可以在任务间传递消息内容或消息的地址。内核用队列控制块来管理消息队列，同时又使用双向环形链表来管理控制块。

队列控制块：管理具体消息队列的数据块，内核初始化时调用OsQueueInit()创建，并依次挂载到双向环形链表g_freeQueueList中，此时控制块状态为OS\_QUEUE\_UNUSED，队列控制块用来保存队列的状态，队列长度、消息长度、队列ID、队列头尾位置和等待读写的任务列表，内核就是根据这些信息来管理消息队列和任务完成对消息读写等操作。

 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;
    }LosQueueCB;　　

初始化后队列控制块的组织方式如下：

创建队列：队列用于存放具体的消息内容，任务可以调用LOS\_QueueCreate()来创建队列，此时内核会根据入参指定的队列长度和消息大小申请内存创建队列，并从g\_freeQueueList中分配一个控制块来管理队列，被分配的队列控制块状态为OS\_QUEUE\_INUSED。分配队列控制块时总是从头节点开始，如下图控制块０首先被分配用于管理新创建的队列。

写队列：内核支持两种写队列方式：从尾部写入LOS\_QueueWrite()和 从头部写入LOS\_QueueWriteHead()：

读队列：读队列只有一种方式，从队列头部读LOS\_QueueRead()，读取之后head指向下个节点。

删除队列：当不再使用队列时可以使用LOS\_QueueDelete()来删除队列，此时会归还队列控制块到g_freeQueueList中，并释放消息队列：

三、数据结构--事件​

事件用于实现任务间的同步，但事件通信只能是事件类型的通信，无数据传输，事件控制块由任务申请，内核负责维护。

事件控制块：事件控制块用来记录事件和管理等待读取事件的任务。uwEventID总共32bit代表31个事件（bit25保留），stEventList事件控制块的双向环形链表，当有任务读取事件但事件还没发生时任务会被挂载链表中，当事件发生时系统唤醒等待事件的任务，此时任务就会被摘出链表。

  typedef struct tagEvent {
        UINT32 uwEventID;       
        LOS_DL_LIST stEventList;  
    } EVENT_CB_S, *PEVENT_CB_S;

事件初始化：事件控制块由任务创建，然后调用LOS_EventInit()进行初始化，初始化后的状态如下：

事件读：当事件没有发生时，读事件操作会引发系统调度，把当前任务挂起并加入到stEventList链表，下图中事件1发生，任务Task1读取事件2，但是事件2没有发生导致Task1被挂起。

事件写：当事件2发生时，任务Task2把事件2写入uwEventID，此时任务Task1被调度读取事件成功，事件2对应bit位被清0（也可以不清0），Task1从链表stEventList中被摘出。

事件删除：事件控制块是由任务创建的，内核不负责控制块的删除，但是任务可以调用LOS\_EventClear来清除事件。

四、数据结构--互斥锁​

互斥锁又称互斥型信号量，是一种特殊的二值性信号量，用于实现对共享资源的独占式处理。任意时刻互斥锁的状态只有开锁或闭锁，当有任务持有时，互斥锁处于闭锁状态，任务获得该互斥锁的所有权；当该任务释放它时，互斥锁被开锁，任务失去该互斥锁的所有权；当一个任务持有互斥锁时，其他任务将不能再对该互斥锁进行开锁或持有。

互斥锁控制块：互斥锁控制块资源由内核创建和维护，内核初始化时会调用函数OsMuxInit()对锁资源进行初始化。等待互斥锁的任务会被挂载到muxList中。 

    typedef struct {
            UINT8 muxStat;       /**< State OS_MUX_UNUSED,OS_MUX_USED  */
            UINT16 muxCount;     /**< Times of locking a mutex */
            UINT32 muxID;        /**< Handle ID */
            LOS_DL_LIST muxList; /**< Mutex linked list */
            LosTaskCB *owner;    /**< The current thread that is locking a mutex */
            UINT16 priority;     /**< Priority of the thread that is locking a mutex */
    } LosMuxCB;

初始化时内核会申请LOSCFG\_BASE\_IPC\_MUX\_LIMIT个锁资源，并把各资源块挂载到双向环形链表g\_unusedMuxList中，全局变量g\_allMux指向锁资源内存首地址，后续根据首地址加ID方式快速查找对应的控制块：

互斥锁创建：任务调用LOS\_MuxCreate()创建互斥锁，内核会从g_unusedMuxList的头部分配一个锁资源给任务。

互斥锁申请：任务调用LOS\_MuxPend()申请互斥锁，如果锁被其它任务持有，则任务在muxList上排队。

互斥锁释放：任务调用LOS\_MuxPost()释放互斥锁，如果有其它任务排队，则触发调度释放锁给排队任务。

互斥锁删除：任务调用LOS\_MuxDelete()删除互斥锁，如果删除成功锁资源被归还到g\_unusedMuxList中。

五、数据结构--信号量​

信号量实现任务之间同步或临界资源的互斥访问的一种同步机制，常用于协助一组相互竞争的任务来访问临界资源。在多任务系统中，各任务之间需要同步或互斥实现临界资源的保护，信号量功能可以为用户提供这方面的支持。通常一个信号量的计数值用于对应有效的资源数，表示剩下的可被占用的互斥资源数。

信号量控制块：信号量控制块资源由内核创建和维护，内核初始化时会调用函数OsSemInit()对信号量资源进行初始化。初始化时申请LOSCFG\_BASE\_IPC\_SEM\_LIMIT个信号量控制块，g\_allSem指向信号量控制块的首地址，创建好的信号量控制块会挂载到空闲链表g\_unusedSemList中。申请信号量的任务会在控制块的链表semList上排队，semCount指示可以被访问的资源数。

    typedef struct {
            UINT16 semStat;      /**< Semaphore state */
            UINT16 semCount;     /**< Number of available semaphores */
            UINT16 maxSemCount;  /**< Max number of available semaphores */
            UINT16 semID;        /**< Semaphore control structure ID */
            LOS_DL_LIST semList; /**< Queue of tasks that are waiting on a semaphore */
    } LosSemCB;

信号量创建：任务调用LOS\_SemCreate()创建信号量，并指定同一时刻访问此资源的最大任务数目。内核从g\_unusedSemList的头部分配一个信号量控制块并初始化。

信号量申请：任务调用LOS\_MuxPend()申请信号量，如果有资源可以访问则申请成功，否则在semList上排队等候。

信号量释放：任务调用LOS\_SemPost()释放信号量，如果有其它任务排队，则触发调度使排队任务访问资源。

信号量删除：任务调用LOS\_SemDelete()删除信号量，如果删除成功，锁资源被归还到g\_unusedSemList的头部。

六、总结​

本篇文章通过数据结构的队列、事件、互斥锁、信号量四大方面对内核IPC机制数据结构进行解析，希望以上的讲解能给大家建立一个IPC机制的整体认识。关于OpenHarmony 内核的内容，之前我还介绍了内核对象队列的算法以及OpenHarmony LiteOS-M 内核事件的运作机制，感兴趣的读者可以点击阅读：《​​OpenHarmony——内核对象队列之算法详解（上）​​》、《​​OpenHarmony——内核对象队列之算法详解（下）​​》、《​​OpenHarmony——内核对象事件之源码详解​​》。

纸上得来终觉浅，绝知此事要躬行。所有知识转化为能力，都必须躬身实践，愿所有热爱OpenHarmony的开发者，在未来的开发工作中学真知、悟真谛，加强磨炼、增长本领，为OpenHarmony生态的繁荣发展不断前行！