OpenHarmony-內核對象事件之源碼詳解
前言
OpenHarmony的事件提供一種任務間的同步機制，簡單來說就是一個或多個任務可以通過寫一個或多個不同的事件來觸發內核調度讓另一個等待讀取事件的任務進入運行狀態，從而實現任務間的同步。具體是怎么實現的呢?今天我就帶大伙深入到內核當中，扒一扒事件的源代碼。
關鍵數據結構
在解讀事件的源碼之前還是要先了解下事件的關鍵的數據結構PEVENT_CB_S，數據結構永遠是內核學習繞不開的坎：
typedef struct tagEvent {
UINT32 uwEventID;
LOS_DL_LIST stEventList; /**< Event control block linked list */
} EVENT_CB_S, *PEVENT_CB_S;
- uwEventID：標記任務的事件類型，每個bit可以標識一個事件最多支持31個事件(第25bit保留)。
- stEventList：事件控制塊的雙向循環鏈表，理解這個字段是理解事件的關鍵。在雙向循環鏈表中唯一不變的節點就是頭節點，而這里的stEventList就是頭節點。當有任務等待事件但事件還沒發生時任務會被掛載到等待鏈表中，當事件發生時系統喚醒等待事件的任務，此時任務就會被剔出鏈表。
事件初始化
下面是事件初始化源碼：
LITE_OS_SEC_TEXT_INIT UINT32 LOS_EventInit(PEVENT_CB_S eventCB)
{
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是指針，是指針，是指針，重要的話說三遍哈。
側面也說明事件控制塊由任務自己創建，內核事件模塊只負責維護。到這里大伙就知道怎么創建事件控制塊了吧，任務定義自己的事件控制塊變量，然后通過LOS_EventInit來初始化，此時沒有事件發生，當然事件鏈表空空如也。
用圖來表達就是：
事件寫操作
任務可以通過LOS_EventWrite來寫觸發一個或多個事件：
LITE_OS_SEC_TEXT UINT32 LOS_EventWrite(PEVENT_CB_S eventCB, UINT32 events)
{
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處，有事件發生了就該檢查是否有任務在等待事件，事件鏈表不為空說明有任務在等待事件。
3處，遍歷事件鏈表，喚醒符合條件的任務。LOS_DL_LIST_ENTRY((&eventCB->stEventList)->pstNext, LosTaskCB, pendList) 前面說過頭節點是空節點，第一次遍歷從頭節點的下一個節點開始，后續順藤摸瓜 依次找出nextTask，直到回到頭節點。
4處，針對事件讀取模式，找到滿足條件的任務并喚醒該任務。
5處，一旦匹配到等待事件的任務，則執行任務調度，被喚醒的任務得到執行。
寫事件實際操作如下圖：
事件讀操作
LiteOS為用戶提供了兩個事件讀函數:
- LOS_EventPoll():根據任務傳入的事件值、掩碼及校驗模式，返回滿足條件的事件，任務可以主動檢查事件是否發生而不必被掛起。
- LOS_EventRead():讀取事件，可以理解為阻塞式讀，如果事件沒有發生，可以指定等待時間，掛起當前任務;
下面是LOS_EventPoll()的實現：
LITE_OS_SEC_TEXT UINT32 LOS_EventPoll(UINT32 *eventID, UINT32 eventMask, UINT32 mode)
{
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,只要有一個事件發生則讀取成功,返回發生的那個事件。
2處，如果讀取模式LOS_WAITMODE_AND,全部檢查事件發生才算讀取成功，并返回全部發生事件。
3處，事件讀取成功后事件控制塊中的事件標記怎么處理?這里通過LOS_WAITMODE_CLR來決定是否清除事件標記。
可以看出以上實現了兩種事件讀取方式：多個事件只要一個發生就算發生和全部事件發生才算發生。
下面是LOS_EventRead()：
LITE_OS_SEC_TEXT UINT32 LOS_EventRead(PEVENT_CB_S eventCB, UINT32 eventMask, UINT32 mode, UINT32 timeOut)
{
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處，主動查詢想要的事件是否已經發生。
2處，如果事件沒有發生，就把當前任務掛起到等待事件鏈表中。
3處，如果事件沒有發生，當前讀事件的任務被掛起，讓出CPU。
4處，事件發生時等待事件的任務被調度再次獲得CPU恢復執行，讀取事件。
事件讀寫整個過程串起來如下圖所示：
事件銷毀操作
做事有始有終，事件消費完成剩下的事情當然是清除事件和等待事件的任務鏈表。
LITE_OS_SEC_TEXT_MINOR UINT32 LOS_EventClear(PEVENT_CB_S eventCB, UINT32 eventMask)
{
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中清空事件鏈表指針。
小結
事件模塊本身并不復雜，相信看了上面的描述大伙對事件的運作機制已經有了更深刻的理解，下面我們來個總結：
- 事件控制塊由任務創建，事件模塊本身只維護事件控制塊的內容。
- 寫事件會觸發讀事件任務被喚醒，任務調度就這么發生了。
- 任務可以主動查詢事件，也可以被動等待事件發生時來喚醒自己。
- 事件結束后根據應用場景可以有選擇的清除事件ID或(和)事件鏈表。
