【鸿蒙南向开发】对OpenHarmony中LiteOS的内核分析—

本文链接：https://blog.csdn.net/HarmonyOS_666/article/details/140779333

前言

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

● 当前线程暂时休眠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中的实现，从原理，使用以及具体实现细节上进行了详尽讨论，并归纳整理了当前这种实现方式所带来的益处。