Kernel Analysis of LiteOS in OpenHarmony - Timeout Principle and Application

foreword

In the software world, timeout is a very important concept. For example ● The current thread temporarily sleeps for 1 second, and continues to execute after the sleep is over ● Collect CPU utilization every 5 seconds ● If data transmission fails, try again after 2 seconds ● Wait for some kind of data, but at most 50 milliseconds

application

//Sleep the current task for a number of ticks, tick is the time unit, the common value is 10 milliseconds
LITE_OS_SEC_TEXT UINT32 LOS_TaskDelay(UINT32 tick)
//Get the semaphore semHandle, if the current semaphore is unavailable and the timeout is not 0, wait at most the time specified by the timeout. If the semaphore is available during this time, the acquisition succeeds, otherwise the acquisition fails.
LITE_OS_SEC_TEXT UINT32 LOS_SemPend(UINT32 semHandle, UINT32 timeout)
//When reading a message from an empty message queue, or writing a message to a full message queue, if the timeout is not 0, wait up to the time specified by the timeout. During this time, the message queue is readable or writable, and then the Corresponding read and write and return success, otherwise return failure.
LITE_OS_SEC_TEXT UINT32 LOS_QueueRead(UINT32 queueID, VOID *bufferAddr, UINT32 bufferSize, UINT32 timeOut)
LITE_OS_SEC_TEXT UINT32 LOS_QueueWrite(UINT32 queueID, VOID *bufferAddr, UINT32 bufferSize, UINT32 timeOut)
//Obtain the mutex lock. If the current mutex lock is occupied by other threads, it will wait up to the time specified by timeout. During this time, if other threads release the mutex lock and are grabbed by this thread, it will return success, otherwise it will return failure.
LITE_OS_SEC_TEXT UINT32 LOS_MuxPend(UINT32 muxHandle, UINT32 timeout)
//Wait for other threads to send events to this thread, up to the time specified by timout
LITE_OS_SEC_TEXT UINT32 LOS_EventRead(PEVENT_CB_S eventCB, UINT32 eventMask, UINT32 mode, UINT32 timeOut)
The above functions are all specific applications of the timeout concept in the liteos_m kernel in OpenHarmony.
Specifically, how does the liteos_m kernel implement this timeout logic, let's move on to the next chapter

principle

As shown in FIG. On the timeline, the yellow dots represent the time points when some operation needs to be performed, and the green dots are the check time points to check whether the system has a timeout event that needs to be processed. The system is checked periodically (the unit of period is tick). There may or may not be a timeout event between 2 checkpoints.
For example, according to the situation shown in the figure above. Currently at the first checkpoint, 2 timeout events are found, then these 2 timeout events are processed this time; as time goes by, the arrow comes to the second checkpoint, and 2 timeout events are found, continue processing; At the third checkpoint, there is no timeout event within this period, so it is a no-op. Subsequent checks and so on.

Code

For accuracy and timeliness, this article selects the latest version of the code to describe. The above checkpoints and time points are defined by a linked list structure. Specifically in the kernel/liteos_m/include/los_sortlink.h file.

Since the timeout events in the schematic diagram are non-uniform, and there is an orderly and sequential logic, this information is maintained in a doubly linked list (which is more friendly to delete operations).
SortLinkList represents each time point in the linked list that needs to process the event, and responseTime represents the specific time value (the number of cpu cycles since startup). SortLinkAttribute represents the head (dumb head) of the linked list. As can be seen from the name, this is a sorted doubly linked list, and the sorting is based on the value of responseTime.
One detail to note is that the system supports 2 linked lists, one of which is a TASK linked list and the other is a SWTMR linked list. The two linked lists are implemented in the same way. The main difference is that the timeout processing of the SWTMR linked list is to wake up the swtmr thread to process the timeout event, while the task linked list wakes up each specific task (sleep, ipc timeout and other scenarios). Using the swtmr thread to handle several timeout mechanisms can effectively reduce the number of threads required by the system, thereby saving system resources.

Summarize

This paper describes the implementation of the timeout logic in OpenHarmony, discusses the principle, usage and specific implementation details in detail, and summarizes the benefits brought by the current implementation.