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;