看代码时冒出个想法

白手梦想家

看代码时冒出个想法 [复制链接]

看到raw_tick.c里面的

更新系统滴答。uCOS里面是遍历一遍等待中的所有进程，将其cnt--。这里好像也是遍历？？
我想如果改成下面方案，速度可能更快？
下面这是等待节点：
wait_node<——>wait_node<——>wait_node<——>wait_node
每个节点保存的是比上一个节点多的时间。
比如，对应上面：
100ms（绝对值）<——>20ms（相对值）<——>20ms（相对值）<——>20ms（相对值）
即：
100ms（绝对值）<——>120ms（绝对值）<——>140ms（绝对值）<——>160ms（绝对值）
每次更新只需要对第一个等待节点减1，如果为0，去掉头节点，并检查第二个节点，如果第二个节点为0，同样操作，再检查第三个节点，直到不为0。

问题是，作为参考的第一个延时节点的绝对值怎么知道？在链表建立第一个节点的时候就保存其延时的绝对值，每从头部去掉一个节点，更新此绝对值。每添加一个节点，以头节点的绝对值作为参考，求出相对延时时间，放到等待节点中，并进行根据大小，插入到相应的位置，插入排序貌似挺快的。

最后的问题是如果这样，貌似插入的时间就不确定了？就不算实时了？

勿喷。

q205209

白手梦想家

q205209 发表于 2016-5-28 14:28

新手水贴，后面加n个空格，只要够30字就能加2个经验一个芯币，我会乱说

dj狂人

白手梦想家 发表于 2016-5-28 14:56
新手水贴，后面加n个空格，只要够30字就能加2个经验一个芯币，我会乱说

这里水经验没有必要。不过论坛好像有个专门的水群

jorya_txj

因为系统中超时的任务是有限的，所以插入排序计算量是非常有限的，基本时间可以忽略，不影响实时性。

白手梦想家

jorya_txj 发表于 2016-5-28 21:53
因为系统中超时的任务是有限的，所以插入排序计算量是非常有限的，基本时间可以忽略，不影响实时性。

版主我想问问这个方案是不是可行呢

科技猎人

你的思路大方向是对的，你可以看看rtthread里面的是如何处理的，我的MsgOS和rtthread思路差不多实现细节上有些区别。其实延时任务少的话怎么处理都行。

白手梦想家

科技猎人 发表于 2016-6-6 17:21
你的思路大方向是对的，你可以看看rtthread里面的是如何处理的，我的MsgOS和rtthread思路差不多实现细节上 ...

实时嘛，尽量提高效率嘛，我看了uC/OS-II和raw-os的，都差不多是遍历，这方面是不是应该特别优化一下，毕竟时钟滴答是很频繁的，而且越快越好，rtthread只看了一点，还请指教

jorya_txj

白手梦想家 发表于 2016-6-7 20:08
实时嘛，尽量提高效率嘛，我看了uC/OS-II和raw-os的，都差不多是遍历，这方面是不是应该特别优化一下，毕 ...

raw-os 2.x 采取的是hash 的做法，插入的时候是找到头结点然后插入。tick中断的时候基本是o(1),一步到位找到。
更重要的是raw-os的tick中断处理可以是外面的任务处理的，不会阻塞其他更高优先级的任务和中断。