对 OpenHarmony 中 LiteOS 的内核分析——超时原理和应用

前言

在软件世界里面，超时是一个非常重要的概念。比如

● 当前线程暂时休眠 1 秒钟，休眠结束后继续执行

● 每 5 秒钟采集一下 CPU 利用率

● 数据发送失败，2 秒钟以后再试一试

● 等待某种数据，但最多等待 50 毫秒

应用

//将当前任务休眠若干 tick 数，tick 为时间单位，常见值为 10 毫秒

LITE_OS_SEC_TEXT UINT32 LOS_TaskDelay(UINT32 tick)

//获取信号量 semHandle, 如果当前信号量不可用且 timeout 不为 0，则最多等待 timeout 所指定的时间，在这段时间内如果信号量可用，则获取成功，否则获取失败。

LITE_OS_SEC_TEXT UINT32 LOS_SemPend(UINT32 semHandle, UINT32 timeout)

//从空的消息队列读取消息，或者向满的消息队列写消息时，如果 timeout 不为 0，则最多等待 timeout 指定的时间，在这段时间内消息队列可读或可写，则进行对应的读写并返回成功，否则返回失败。

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)

//获取互斥锁，如果当前互斥锁被其它线程占用，则最多等待 timeout 指定的时间，此时间内其它线程释放了互斥锁并被本线程抢到则返回成功，否则返回失败。

LITE_OS_SEC_TEXT UINT32 LOS_MuxPend(UINT32 muxHandle, UINT32 timeout)

//等待其它线程向本线程发送事件，最多等待 timout 指定的时间

LITE_OS_SEC_TEXT UINT32 LOS_EventRead(PEVENT_CB_S eventCB, UINT32 eventMask, UINT32 mode, UINT32 timeOut)

上述这些函数都是超时概念在 OpenHarmony 中 liteos_m 内核里的具体应用。

具体而言，liteos_m 内核如何实现这个超时逻辑的呢，我们接着看下一个章节

原理

如上图所示。在时间轴上，黄色圆点代表需要进行某种操作的时间点，而绿色圆点为检查系统是否有超时事件需要处理的检查时间点。系统周期性的进行检查(周期单位为 tick)。在 2 个检查点之间可能有超时事件，也可能无超时事件。

例如，根据上图展示的情况。当前在第一个检查点，发现了 2 个超时事件，那么这次处理这 2 个超时事件；随着时间流逝，箭头来到第 2 个检查点，又发现 2 个超时事件，继续处理；在第 3 个检查点时，本段时间内无超时事件，所以是空操作。后续的检查以此类推。

代码实现

为了准确性以及时效性，本文选取了最新的版本的代码来描述。上述检查点和时间点由链表结构进行定义。具体在 kernel/liteos_m/include/los_sortlink.h 文件中。

由于原理图中的超时事件发生是非均匀的，且存在有序依次发生的逻辑，所以，这些信息被维护在双向链表中(对删除操作更友好)。

SortLinkList 代表了链表中的每一个需要处理事件的时间点，responseTime 代表具体的时间值(从启机开始的 cpu cycle 数目)。SortLinkAttribute 代表链表的头部(哑头)。从名称也能看出，这个是一个排序的双向链表，排序的依据即 responseTime 这个数值。

需要注意的一个细节是：系统支持 2 个链表，其中一个是 TASK 链表，另一个是 SWTMR 链表。这 2 个链表实现方式一致，主要区别是，SWTMR 链表超时处理是唤醒 swtmr 线程来处理超时事件，而 task 链表唤醒的是每个具体的 task(sleep，ipc 超时等场景)。使用 swtmr 线程来处理若干超时的机制，可以有效减少系统需要的线程数目，从而节省系统资源的占用。

总结

本文描述了超时逻辑在 OpenHarmony 中的实现，从原理，使用以及具体实现细节上进行了详尽讨论，并归纳整理了当前这种实现方式所带来的益处。