Openharmony - detailed source code of Kernel Object Events

In recent years , Domestic open source to achieve leapfrog development , And become an enterprise to improve its innovation ability 、 Productivity 、 Key to collaboration and transparency . As  OpenAtom OpenHarmony（ hereinafter referred to as “OpenHarmony”） One of the co construction units of open source projects , Shenkaihong takes becoming the leader of intelligent IOT operating system as its strategic goal , be based on  OpenHarmony  Focus on Intelligent Internet of things operating system （KaihongOS） Technology R & D and continuous innovation .

As shenkaihong  OS  Kernel developer , We plough deeply all the year round  OpenHarmony  Kernel development , I hope to share some work experience , Help you master open source knowledge .

OpenHarmony LiteOS-M  The kernel is oriented to  IoT  The lightweight Internet of things operating system kernel built in the field , Have a small volume 、 low power consumption 、 High performance features , Its code structure is simple , Realized the process 、 Threads 、 Memory and other management mechanisms , Provides common task rooms  IPC、 Soft timer and other common modules , It greatly reduces the difficulty of embedded device development . at present  OpenHarmony  The event of provides an inter task  IPC, That is, one or more tasks can trigger kernel scheduling by writing one or more different events , Put another task waiting to read events into running state , So as to realize the synchronization between tasks .

For embedded developers and technology enthusiasts , Learn more about common tasks  IPC, Help learn and develop the kernel . This article will analyze from data structure and algorithm  OpenHarmony  Event mechanism , Let's have a deep understanding of the kernel tasks  IPC  principle .

Key data structure

Before reading the source code of the event , First, understand the key data structure of the next event  PEVENT_CB_S：

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


uwEventID：

That is, mark the event type of the task , Every bit Can identify an event , Most support  31  Events （ The first  25bit  Retain ）.

stEventList：

That is, the bidirectional circular linked list of the event control block , Understanding this field is the key to understanding events . The only constant node in a two-way circular linked list is the head node , And here it is  stEventList  It's the head node . When there is a task waiting for an event, but the event has not yet occurred , The task will be attached to the waiting list ; When the event occurs , The system wakes up tasks waiting for events , The task will be removed from the linked list .

Event initialization

The following is the event initialization source code ：

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  amount to  EVENT_CB_S *,  therefore  eventCB  Is a pointer .

Explain that the event control block is created by the task itself , The kernel event module is only responsible for maintenance . The task defines its own event control block variables , adopt  LOS_EventInit  initialization , No event has occurred at this time , The event linked list is empty .

To express it in a diagram is ：

Event write operation

Tasks can be done through  LOS_EventWrite  To trigger one or more events ：

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 It's about , Save the or operation used by the event , So one or more tasks can write one or more events , Write once or more , And each time for a different event , Writing the same event multiple times is equivalent to writing it only once ;

2 It's about , When an event occurs, it is necessary to check whether there are tasks waiting for the event , The event linked list is not empty, indicating that there are tasks waiting for events ;

3 It's about , Traverse the event list , Wake up qualified tasks .

LOS_DL_LIST_ENTRY((&eventCB->stEventList)->pstNext,LosTaskCB,pendList)  Mentioned earlier , The head node is an empty node , The first traversal starts from the next node of the head node , Then find out in turn  nextTask, Until the node returns to the head ;

4 It's about , Read mode for events , Find the task that meets the condition and wake it up ;

5 It's about , Once the task waiting for the event is matched , Then execute task scheduling , The awakened task is performed .

The actual operation of writing events is shown in the following figure ：

Event read operation

LiteOS  Functions that provide users with two events ：

● LOS_EventPoll()： According to the event value passed in by the task 、 Mask and verification mode , Return the event that meets the condition , The task can actively check whether the event occurs without being suspended ;

● LOS_EventRead()： Read event , It can be understood as blocking reading , If it doesn't happen , You can specify the waiting time , Suspend current task .

Here is  LOS_EventPoll()  The implementation of the ：

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 It's about , If the read mode is LOS_WAITMODE_OR, As long as one event occurs, the reading succeeds , Return to the event that occurred ;

2 It's about , If the read mode LOS_WAITMODE_AND, Reading is successful only when all check events occur , And return all occurrences ;

3 It's about , How to handle the event tag in the event control block after the event is successfully read ？ Through here LOS_WAITMODE_CLR To decide whether to clear the event marker .

It can be seen that the above two event reading methods are implemented ： One is that multiple events can occur as long as one event occurs , The other is that only when all events occur .

Here is  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 It's about , Actively query whether the desired event has occurred ;

2 It's about , If it doesn't happen , Hang the current task in the waiting event list ;

3 It's about , If it doesn't happen , The task of reading the current event is suspended , Give up  CPU;

4 It's about , When the event occurs, the task waiting for the event is scheduled to be obtained again  CPU  Resume execution , Read event .

The whole process of event reading and writing is linked as shown in the following figure ：

Event destroy

The event destruction operation starts and ends , After the event consumption is completed, the remaining tasks are to clear the event and wait for the event .

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;
 ...
}


stay  LOS_EventClear  By making  eventMask=0  To clear the event , stay  LOS_EventDestroy  Clear event linked list pointer in .

Summary

Look at the description above , I'm sure you're right  OpenHarmony LiteOS-M  The operating mechanism of kernel events has been better understood , Developers can better use the... Of events  API  To synchronize tasks , You can also try to modify the kernel event notification mechanism further , Make a better one for your task IPC Mechanism .

OpenHarmony  Ecological construction is inseparable from the participation of every developer , I hope more developers can share their experience and achievements in open source projects , Jointly  OpenHarmony  Contribute to ecological construction .