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

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。

如果你需要这些资料，可以戳这里获取

需要这些体系化资料的朋友，可以加我V获取：vip1024c （备注嵌入式）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

五、数据结构–信号量

六、总结

---

一、前言

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的头部分配一个锁资源给任务。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

需要这些体系化资料的朋友，可以加我V获取：vip1024c （备注嵌入式）

如果你需要这些资料，可以戳这里获取

文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新**

需要这些体系化资料的朋友，可以加我V获取：vip1024c （备注嵌入式）

如果你需要这些资料，可以戳这里获取