OpenHarmony內(nèi)核任務間IPC原理

近年來，國內(nèi)開源實現(xiàn)跨越式發(fā)展，并成為企業(yè)提升創(chuàng)新能力、生產(chǎn)力、協(xié)作和透明度的關鍵。作為 OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）開源項目共建單位之一，深開鴻以成為智能物聯(lián)網(wǎng)操作系統(tǒng)領軍者為戰(zhàn)略目標，基于 OpenHarmony 聚焦智能物聯(lián)網(wǎng)操作系統(tǒng)（KaihongOS）的技術研發(fā)與持續(xù)創(chuàng)新。

身為深開鴻 OS 內(nèi)核開發(fā)師，我們常年深耕于 OpenHarmony 的內(nèi)核開發(fā)，希望通過分享一些工作上的經(jīng)驗，幫助大家掌握開源知識。

OpenHarmony LiteOS-M 內(nèi)核是面向 IoT 領域構建的輕量級物聯(lián)網(wǎng)操作系統(tǒng)內(nèi)核，具有小體積、低功耗、高性能的特點，其代碼結構簡單，實現(xiàn)了進程、線程、內(nèi)存等管理機制，提供了常見任務間 IPC、軟定時器等公共模塊，大幅度降低了嵌入式設備開發(fā)的難度。目前 OpenHarmony 的事件提供一種任務間的 IPC，即一個或多個任務可以通過寫一個或多個不同的事件來觸發(fā)內(nèi)核調(diào)度，讓另一個等待讀取事件的任務進入運行狀態(tài)，從而實現(xiàn)任務間的同步。

對于嵌入式開發(fā)工作人員和技術愛好者來說，深入了解常見任務間 IPC，有助于學習和研發(fā)內(nèi)核。本文將從數(shù)據(jù)結構和算法解析 OpenHarmony 的事件機制，帶大家深入了解內(nèi)核任務間 IPC 原理。

關鍵數(shù)據(jù)結構

在解讀事件的源碼之前，首先了解下事件的關鍵的數(shù)據(jù)結構 PEVENT_CB_S：

typedefstructtagEvent{    UINT32 uwEventID;           LOS_DL_LIST stEventList; /**< Event control block linked list */  } EVENT_CB_S, *PEVENT_CB_S;

uwEventID：即標記任務的事件類型，每個bit可以標識一個事件，最多支持 31 個事件（第 25bit 保留）。

stEventList：即事件控制塊的雙向循環(huán)鏈表，理解這個字段是理解事件的關鍵。在雙向循環(huán)鏈表中唯一不變的節(jié)點就是頭節(jié)點，而這里的 stEventList 就是頭節(jié)點。當有任務等待事件但事件還沒發(fā)生時，任務會被掛載到等待鏈表中；當事件發(fā)生時，系統(tǒng)喚醒等待事件的任務，此時任務就會被剔出鏈表。

事件初始化

下面是事件初始化源碼：

LITE_OS_SEC_TEXT_INITUINT32LOS_EventInit(PEVENT_CB_SeventCB){    if (eventCB == NULL) {        return LOS_ERRNO_EVENT_PTR_NULL;    }    eventCB->uwEventID = 0;    LOS_ListInit(&eventCB->stEventList);    OsHookCall(LOS_HOOK_TYPE_EVENT_INIT, eventCB);    return LOS_OK;}

PEVENT_CB_S 相當于 EVENT_CB_S *， 因此 eventCB 是指針。

說明事件控制塊由任務自己創(chuàng)建，內(nèi)核事件模塊只負責維護。任務定義自己的事件控制塊變量，通過 LOS_EventInit 初始化，此時沒有事件發(fā)生，事件鏈表為空。

用圖來表達就是：

事件寫操作

任務可以通過 LOS_EventWrite 來寫觸發(fā)一個或多個事件：

LITE_OS_SEC_TEXTUINT32LOS_EventWrite(PEVENT_CB_SeventCB,UINT32events){    ...    eventCB->uwEventID |= events;                    ---1    if (!LOS_ListEmpty(&eventCB->stEventList)) {     ---2        for (resumedTask = LOS_DL_LIST_ENTRY((&eventCB->stEventList)->pstNext, LosTaskCB, pendList);             &resumedTask->pendList != (&eventCB->stEventList);) { -------3            nextTask = LOS_DL_LIST_ENTRY(resumedTask->pendList.pstNext, LosTaskCB, pendList);
            if (((resumedTask->eventMode & LOS_WAITMODE_OR) && (resumedTask->eventMask & events) != 0) ||                ((resumedTask->eventMode & LOS_WAITMODE_AND) &&                 ((resumedTask->eventMask & eventCB->uwEventID) == resumedTask->eventMask))) {                exitFlag = 1;
                OsSchedTaskWake(resumedTask);       ---4            }            resumedTask = nextTask;        }
        if (exitFlag == 1) {            LOS_IntRestore(intSave);            LOS_Schedule();                        ---5            return LOS_OK;        }    }    ...}

1處，保存事件使用的或運算操作，因此一個或多個任務可以寫一個或多個事件，寫一次或多次，而且每次為不同的事件，多次寫同一個事件相當于只寫了一次；

2處，有事件發(fā)生了就該檢查是否有任務在等待事件，事件鏈表不為空說明有任務在等待事件；

3處，遍歷事件鏈表，喚醒符合條件的任務。LOS_DL_LIST_ENTRY((&eventCB->stEventList)->pstNext,LosTaskCB,pendList) 前面提到，頭節(jié)點是空節(jié)點，第一次遍歷從頭節(jié)點的下一個節(jié)點開始，后續(xù)再依次找出 nextTask，直到回到頭節(jié)點；

4處，針對事件讀取模式，找到滿足條件的任務并喚醒該任務；

5處，一旦匹配到等待事件的任務，則執(zhí)行任務調(diào)度，被喚醒的任務得到執(zhí)行。

寫事件實際操作如下圖：

事件讀操作

LiteOS 為用戶提供了兩個事件的函數(shù)：

● LOS_EventPoll()：根據(jù)任務傳入的事件值、掩碼及校驗模式，返回滿足條件的事件，任務可以主動檢查事件是否發(fā)生而不必被掛起；

● LOS_EventRead()：讀取事件，可以理解為阻塞式讀，如果事件沒有發(fā)生，可以指定等待時間，掛起當前任務。

下面是 LOS_EventPoll() 的實現(xiàn)：

LITE_OS_SEC_TEXTUINT32LOS_EventPoll(UINT32*eventID,UINT32eventMask,UINT32mode){    UINT32 ret = 0;    UINT32 intSave;
    if (eventID == NULL) {        return LOS_ERRNO_EVENT_PTR_NULL;    }    intSave = LOS_IntLock();    if (mode & LOS_WAITMODE_OR) {        if ((*eventID & eventMask) != 0) {      ---1            ret = *eventID & eventMask;        }    } else {        if ((eventMask != 0) && (eventMask == (*eventID & eventMask))) {   ---2            ret = *eventID & eventMask;        }    }    if (ret && (mode & LOS_WAITMODE_CLR)) {   ---3        *eventID = *eventID & ~(ret);    }    LOS_IntRestore(intSave);    return ret;}

1處，如果讀取模式是LOS_WAITMODE_OR，只要有一個事件發(fā)生則讀取成功，返回發(fā)生的那個事件；

2處，如果讀取模式LOS_WAITMODE_AND，全部檢查事件發(fā)生才算讀取成功，并返回全部發(fā)生事件；

3處，事件讀取成功后事件控制塊中的事件標記怎么處理？這里通過LOS_WAITMODE_CLR來決定是否清除事件標記。

可以看出以上實現(xiàn)了兩種事件的讀取方式：一種是多個事件只要一個發(fā)生就算發(fā)生，另一種是全部事件發(fā)生才算發(fā)生。

下面是 LOS_EventRead()：

LITE_OS_SEC_TEXTUINT32LOS_EventRead(PEVENT_CB_SeventCB,UINT32eventMask,UINT32mode,UINT32timeOut){    ...    ret = LOS_EventPoll(&(eventCB->uwEventID), eventMask, mode);           ---1    OsHookCall(LOS_HOOK_TYPE_EVENT_READ, eventCB, eventMask, mode, timeOut);    if (ret == 0) {        if (timeOut == 0) {            LOS_IntRestore(intSave);            return ret;        }
        if (g_losTaskLock) {            LOS_IntRestore(intSave);            return LOS_ERRNO_EVENT_READ_IN_LOCK;        }        runTsk = g_losTask.runTask;        runTsk->eventMask = eventMask;        runTsk->eventMode = mode;        OsSchedTaskWait(&eventCB->stEventList, timeOut);                  ---2        LOS_IntRestore(intSave);        LOS_Schedule();                                                   ---3
        intSave = LOS_IntLock();        if (runTsk->taskStatus & OS_TASK_STATUS_TIMEOUT) {            runTsk->taskStatus &= ~OS_TASK_STATUS_TIMEOUT;            LOS_IntRestore(intSave);            return LOS_ERRNO_EVENT_READ_TIMEOUT;        }
        ret = LOS_EventPoll(&eventCB->uwEventID, eventMask, mode);       ---4    }     ...}

1處，主動查詢想要的事件是否已經(jīng)發(fā)生；

2處，如果事件沒有發(fā)生，就把當前任務掛起到等待事件鏈表中；

3處，如果事件沒有發(fā)生，當前讀事件的任務被掛起，讓出 CPU；

4處，事件發(fā)生時等待事件的任務被調(diào)度再次獲得 CPU 恢復執(zhí)行，讀取事件。

事件讀寫整個過程串起來如下圖所示：

事件銷毀操作

做事有始有終，事件消費完成剩下的事情是清除事件和等待事件的任務鏈表。

LITE_OS_SEC_TEXT_MINORUINT32LOS_EventClear(PEVENT_CB_SeventCB,UINT32eventMask){    ...    eventCB->uwEventID &= eventMask;    ...}

LITE_OS_SEC_TEXT_INIT UINT32 LOS_EventDestroy(PEVENT_CB_S eventCB){    ...    eventCB->stEventList.pstNext = (LOS_DL_LIST *)NULL;    eventCB->stEventList.pstPrev = (LOS_DL_LIST *)NULL;    ...}

在LOS_EventClear 中通過使 eventMask=0 來清空事件，在 LOS_EventDestroy 中清空事件鏈表指針。

小結

看了上面的描述，相信大家對 OpenHarmony LiteOS-M 內(nèi)核事件的運作機制有了更加深刻的理解，開發(fā)者可以更好地使用事件的 API 來進行任務間的同步操作，也可以進一步嘗試修改內(nèi)核事件通知機制，做出一個更適合自己任務的IPC機制。

OpenHarmony 生態(tài)建設離不開每位開發(fā)者的參與，希望有更多的開發(fā)者分享自己開源項目的經(jīng)驗和成果，共同為 OpenHarmony 生態(tài)建設貢獻一份力量。

原文標題：OpenHarmony——內(nèi)核對象事件之源碼詳解

文章出處：【微信公眾號：深開鴻】歡迎添加關注！文章轉載請注明出處。