?

?

蔣衛(wèi)峰

深圳開鴻數(shù)字產(chǎn)業(yè)發(fā)展有限公司

OS內(nèi)核開發(fā)工程師

?

一、前言

OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）是由開放原子開源基金會（OpenAtom Foundation）孵化及運營的開源項目，目標是面向全場景、全連接、全智能時代，基于開源的方式，搭建一個智能終端設備操作系統(tǒng)的框架和平臺，促進萬物互聯(lián)產(chǎn)業(yè)的繁榮發(fā)展。

作為面向全場景、全連接、全智能的分布式泛終端操作系統(tǒng)，OpenHarmony通過將各類不同終端設備的能力進行整合，實現(xiàn)硬件互助、資源共享，為用戶提供流暢的全場景體驗。為了能適應各種硬件，OpenHarmony提供了LiteOS、Linux內(nèi)核，并基于這些內(nèi)核形成了不同的系統(tǒng)類型，同時又在這些系統(tǒng)中構建了一套統(tǒng)一的系統(tǒng)能力。

OpenHarmony LiteOS-M內(nèi)核是面向IoT領域構建的輕量級物聯(lián)網(wǎng)操作系統(tǒng)內(nèi)核，LiteOS-M核為任務間通信提供了多種機制，包括隊列、事件、互斥鎖和信號量。各機制涉及到哪些關鍵數(shù)據(jù)結構？這些數(shù)據(jù)結構又是如何工作的？接下來我將從隊列、事件、互斥鎖、信號量幾個內(nèi)核對象出發(fā)，為大家講解內(nèi)核IPC機制的數(shù)據(jù)結構。

?

二、數(shù)據(jù)結構--隊列

隊列又稱消息隊列，是一種常用于任務間通信的數(shù)據(jù)結構，可以在任務間傳遞消息內(nèi)容或消息的地址。內(nèi)核用隊列控制塊來管理消息隊列，同時又使用雙向環(huán)形鏈表來管理控制塊。 ?

隊列控制塊：管理具體消息隊列的數(shù)據(jù)塊，內(nèi)核初始化時調(diào)用OsQueueInit()創(chuàng)建，并依次掛載到雙向環(huán)形鏈表g_freeQueueList中，此時控制塊狀態(tài)為OS\_QUEUE\_UNUSED，隊列控制塊用來保存隊列的狀態(tài)，隊列長度、消息長度、隊列ID、隊列頭尾位置和等待讀寫的任務列表，內(nèi)核就是根據(jù)這些信息來管理消息隊列和任務完成對消息讀寫等操作。

• ?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• ?
• ?

 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;　　

?

初始化后隊列控制塊的組織方式如下：

?

?

創(chuàng)建隊列：隊列用于存放具體的消息內(nèi)容，任務可以調(diào)用LOS\_QueueCreate()來創(chuàng)建隊列，此時內(nèi)核會根據(jù)入?yún)⒅付ǖ年犃虚L度和消息大小申請內(nèi)存創(chuàng)建隊列，并從g\_freeQueueList中分配一個控制塊來管理隊列，被分配的隊列控制塊狀態(tài)為OS\_QUEUE\_INUSED。分配隊列控制塊時總是從頭節(jié)點開始，如下圖控制塊０首先被分配用于管理新創(chuàng)建的隊列。

?

?

寫隊列：內(nèi)核支持兩種寫隊列方式：從尾部寫入LOS\_QueueWrite()和 從頭部寫入LOS\_QueueWriteHead()：

?

?

讀隊列：讀隊列只有一種方式，從隊列頭部讀LOS\_QueueRead()，讀取之后head指向下個節(jié)點。

?

?

刪除隊列：當不再使用隊列時可以使用LOS\_QueueDelete()來刪除隊列，此時會歸還隊列控制塊到g_freeQueueList中，并釋放消息隊列：

?

三、數(shù)據(jù)結構--事件

事件用于實現(xiàn)任務間的同步，但事件通信只能是事件類型的通信，無數(shù)據(jù)傳輸，事件控制塊由任務申請，內(nèi)核負責維護。 ?

事件控制塊：事件控制塊用來記錄事件和管理等待讀取事件的任務。uwEventID總共32bit代表31個事件（bit25保留），stEventList事件控制塊的雙向環(huán)形鏈表，當有任務讀取事件但事件還沒發(fā)生時任務會被掛載鏈表中，當事件發(fā)生時系統(tǒng)喚醒等待事件的任務，此時任務就會被摘出鏈表。

• ?
• ?
• ?
• ?

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

事件初始化：事件控制塊由任務創(chuàng)建，然后調(diào)用LOS_EventInit()進行初始化，初始化后的狀態(tài)如下：

?

?

事件讀：當事件沒有發(fā)生時，讀事件操作會引發(fā)系統(tǒng)調(diào)度，把當前任務掛起并加入到stEventList鏈表，下圖中事件1發(fā)生，任務Task1讀取事件2，但是事件2沒有發(fā)生導致Task1被掛起。

?

?

事件寫：當事件2發(fā)生時，任務Task2把事件2寫入uwEventID，此時任務Task1被調(diào)度讀取事件成功，事件2對應bit位被清0（也可以不清0），Task1從鏈表stEventList中被摘出。

?

?

事件刪除：事件控制塊是由任務創(chuàng)建的，內(nèi)核不負責控制塊的刪除，但是任務可以調(diào)用LOS\_EventClear來清除事件。

?

?

四、數(shù)據(jù)結構--互斥鎖

互斥鎖又稱互斥型信號量，是一種特殊的二值性信號量，用于實現(xiàn)對共享資源的獨占式處理。任意時刻互斥鎖的狀態(tài)只有開鎖或閉鎖，當有任務持有時，互斥鎖處于閉鎖狀態(tài)，任務獲得該互斥鎖的所有權；當該任務釋放它時，互斥鎖被開鎖，任務失去該互斥鎖的所有權；當一個任務持有互斥鎖時，其他任務將不能再對該互斥鎖進行開鎖或持有。

?

互斥鎖控制塊：互斥鎖控制塊資源由內(nèi)核創(chuàng)建和維護，內(nèi)核初始化時會調(diào)用函數(shù)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;

初始化時內(nèi)核會申請LOSCFG\_BASE\_IPC\_MUX\_LIMIT個鎖資源，并把各資源塊掛載到雙向環(huán)形鏈表g\_unusedMuxList中，全局變量g\_allMux指向鎖資源內(nèi)存首地址，后續(xù)根據(jù)首地址加ID方式快速查找對應的控制塊：

?

?

互斥鎖創(chuàng)建：任務調(diào)用LOS\_MuxCreate()創(chuàng)建互斥鎖，內(nèi)核會從g_unusedMuxList的頭部分配一個鎖資源給任務。

?

?

互斥鎖申請：任務調(diào)用LOS\_MuxPend()申請互斥鎖，如果鎖被其它任務持有，則任務在muxList上排隊。

?

?

互斥鎖釋放：任務調(diào)用LOS\_MuxPost()釋放互斥鎖，如果有其它任務排隊，則觸發(fā)調(diào)度釋放鎖給排隊任務。

?

?

互斥鎖刪除：任務調(diào)用LOS\_MuxDelete()刪除互斥鎖，如果刪除成功鎖資源被歸還到g\_unusedMuxList中。

?

?

五、數(shù)據(jù)結構--信號量

信號量實現(xiàn)任務之間同步或臨界資源的互斥訪問的一種同步機制，常用于協(xié)助一組相互競爭的任務來訪問臨界資源。在多任務系統(tǒng)中，各任務之間需要同步或互斥實現(xiàn)臨界資源的保護，信號量功能可以為用戶提供這方面的支持。通常一個信號量的計數(shù)值用于對應有效的資源數(shù)，表示剩下的可被占用的互斥資源數(shù)。

?

信號量控制塊：信號量控制塊資源由內(nèi)核創(chuàng)建和維護，內(nèi)核初始化時會調(diào)用函數(shù)OsSemInit()對信號量資源進行初始化。初始化時申請LOSCFG\_BASE\_IPC\_SEM\_LIMIT個信號量控制塊，g\_allSem指向信號量控制塊的首地址，創(chuàng)建好的信號量控制塊會掛載到空閑鏈表g\_unusedSemList中。申請信號量的任務會在控制塊的鏈表semList上排隊，semCount指示可以被訪問的資源數(shù)。

• ?
• ?
• ?
• ?
• ?
• ?
• ?

    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;

?

信號量創(chuàng)建：任務調(diào)用LOS\_SemCreate()創(chuàng)建信號量，并指定同一時刻訪問此資源的最大任務數(shù)目。內(nèi)核從g\_unusedSemList的頭部分配一個信號量控制塊并初始化。

?

?

信號量申請：任務調(diào)用LOS\_MuxPend()申請信號量，如果有資源可以訪問則申請成功，否則在semList上排隊等候。

?

?

信號量釋放：任務調(diào)用LOS\_SemPost()釋放信號量，如果有其它任務排隊，則觸發(fā)調(diào)度使排隊任務訪問資源。

?

?

信號量刪除：任務調(diào)用LOS\_SemDelete()刪除信號量，如果刪除成功，鎖資源被歸還到g\_unusedSemList的頭部。

?

?

六、總結

本篇文章通過數(shù)據(jù)結構的隊列、事件、互斥鎖、信號量四大方面對內(nèi)核IPC機制數(shù)據(jù)結構進行解析，希望以上的講解能給大家建立一個IPC機制的整體認識。

關于OpenHarmony 內(nèi)核的內(nèi)容，之前我還介紹了內(nèi)核對象隊列的算法以及OpenHarmony LiteOS-M 內(nèi)核事件的運作機制，感興趣的讀者可以點擊閱讀：《OpenHarmony——內(nèi)核對象隊列之算法詳解（上）》、《OpenHarmony——內(nèi)核對象隊列之算法詳解（下）》、《OpenHarmony——內(nèi)核對象事件之源碼詳解》。

紙上得來終覺淺，絕知此事要躬行。所有知識轉(zhuǎn)化為能力，都必須躬身實踐，愿所有熱愛OpenHarmony的開發(fā)者，在未來的開發(fā)工作中學真知、悟真諦，加強磨煉、增長本領，為OpenHarmony生態(tài)的繁榮發(fā)展不斷前行！