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

发布时间:2022-12-20 13:00

前言

在软件世界里面,超时是一个非常重要的概念。比如
● 当前线程暂时休眠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内核如何实现这个超时逻辑的呢,我们接着看下一个章节

原理

对OpenHarmony中LiteOS的内核分析——超时原理和应用_第1张图片
如上图所示。在时间轴上,黄色圆点代表需要进行某种操作的时间点,而绿色圆点为检查系统是否有超时事件需要处理的检查时间点。系统周期性的进行检查(周期单位为tick)。在2个检查点之间可能有超时事件,也可能无超时事件。
例如,根据上图展示的情况。当前在第一个检查点,发现了2个超时事件,那么这次处理这2个超时事件;随着时间流逝,箭头来到第2个检查点,又发现2个超时事件,继续处理;在第3个检查点时,本段时间内无超时事件,所以是空操作。后续的检查以此类推。

代码实现

为了准确性以及时效性,本文选取了最新的版本的代码来描述。上述检查点和时间点由链表结构进行定义。具体在kernel/liteos_m/include/los_sortlink.h文件中。
对OpenHarmony中LiteOS的内核分析——超时原理和应用_第2张图片
由于原理图中的超时事件发生是非均匀的,且存在有序依次发生的逻辑,所以,这些信息被维护在双向链表中(对删除操作更友好)。
SortLinkList代表了链表中的每一个需要处理事件的时间点,responseTime代表具体的时间值(从启机开始的cpu cycle数目)。SortLinkAttribute代表链表的头部(哑头)。从名称也能看出,这个是一个排序的双向链表,排序的依据即responseTime这个数值。
需要注意的一个细节是:系统支持2个链表,其中一个是TASK链表,另一个是SWTMR链表。这2个链表实现方式一致,主要区别是,SWTMR链表超时处理是唤醒swtmr线程来处理超时事件,而task链表唤醒的是每个具体的task(sleep,ipc超时等场景)。使用swtmr线程来处理若干超时的机制,可以有效减少系统需要的线程数目,从而节省系统资源的占用。

总结

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

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号