OpenHarmony LiteOS-M内核的数据结构

 

 

蒋卫峰

深圳开鸿数字产业发展有限公司

OS内核开发工程师

 

一、前言

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生态的繁荣发展不断前行！