完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
1、对时间片调度算法issue的分析 在之前 rt_schedule中need_insert_from_thread的问题 提问中,笔者提出了当前时间片调度算法过于复杂,且高优先级一旦打断未执行完时间片的任务会导致该任务重新插入到其优先级readylist末尾,存在严重的不公平性(破坏了时间片的连续)。 当然笔者也PR了一个解决方案 暂未合并 最近又有一个小伙伴发现了时间片调度的issue 大致的情况是: 低优先级的存在任务A(ticks = a),B(ticks =b),; 高优先级任务C 如果高优先级 C内存在延时c 正好等于A的时间片a 结果就是低优先级的任务只有A在一直运行, B一直运行不了 这种情况的根本原因其实还是笔者之前提到的高优先级导致当前低优先级任务插入readylist位置不对的issue, 下面笔者再次配重新整理一下这个问题,配合图例逐步分析源码并结合测试例程展示不同情况下该issue导致的问题,并尝试解决。 排除componets中使用的情况,rt_schedule主要在下面情况中被使用 clock.c : 就是刚刚提及的在Systick中断中两种比较重要的调度: 时间片调度和超时调度 ipc.c ,mempool.c: 另外一种比较重要的调度: 资源阻塞和就绪调度(资源调度) scheduler.c, thread.c: 本身调度器和线程API的使用导致的直接API调度 timer.c : 软定时器超时调度,使用的也是_thread_timeout超时函数,也是超时调度 鉴于 API调度一般使用在初始化阶段,Application运行中主要使用的是时间片调度,超时调度,资源调度 。后面的讨论中主要绕后三种展开:
关于时间片调度算法issue的分析与解决.pdf
(1.25 MB, 下载次数: 0
)
原作者:blta |
|
相关推荐
|
|
AI模型部署边缘设备的奇妙之旅:边缘端设备的局域网视频流传输方案
914 浏览 0 评论
1350 浏览 0 评论
AI模型部署边缘设备的奇妙之旅:如何在边缘端部署OpenCV
5505 浏览 0 评论
tms320280021 adc采样波形,为什么adc采样频率上来波形就不好了?
1756 浏览 0 评论
2728 浏览 0 评论
76553 浏览 21 评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-1-8 05:23 , Processed in 0.515496 second(s), Total 66, Slave 47 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (威廉希尔官方网站 图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号