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运行中主要使用的是时间片调度,超时调度,资源调度 。后面的讨论中主要绕后三种展开:
原作者:blta
0
|
|
|
|