【鸿蒙南向开发】OpenHarmony——内核IPC机制数据结构解析-CSDN博客

本文链接：https://blog.csdn.net/HarmonyOS_666/article/details/140773932

一、前言

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机制的整体认识。

写在最后

有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）文档用来跟着学习是非常有必要的。

这份鸿蒙（HarmonyOS NEXT）文档包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony南向开发、鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。