Toggle navigation
首页
问答
文章
积分商城
专家
专区
更多专区...
文档中心
返回主站
搜索
提问
会员
中心
登录
注册
shellstudio
这家伙很懒，什么也没写！
注册于 15年前
回答
5
文章
0
关注者
1
关注TA
向TA提问
发私信
TA的回答
问
关于RTOS中的Timer处理的建议
发布于14年前
事实上，rtt已经作了排序优化。
问
这里是BUG回报板块!
发布于15年前
RTT还需要很长的时间来完善才能用于商业乃至工业现场啊！今天又发现了一个很要命的漏洞，这种漏洞是对临界代码段的理解太随意导致的。 我知道，很多人有时候为了所谓的实时性，都忽略了临界代码段的重要性。但是，如果不仔细推敲代码而随意放任的话，系统会变得异常脆弱！ 下面我就来给你分析以下rt_object_find()函数的漏洞。 rt_object_find()函数是通过对象的名称来查找对象，并返回指针。调用该函数之前，线程大都不会关中断来保护rt_object_find()，而该函数自身更是没有临界段保护措施，这样就造成了下面的漏洞： 在遍历链表节点的过程中，node指向当前所检查的对象节点，而在此判断过程中，有可能高优先级线程得到运行，从而导致当前对象节点有可能被删除，这时，对象的链表指针next,prev就指向它自身。之后，CPU上下文回到调用rt_object_find()函数的线程，继续遍历对象链表，结果node = node->next语句总是使node指向它自身，而且符合node != &(information->object_list)条件，因此，for()循环形成了死循环！该函数将无法退出，其结果无法预测！ 我是一个思维很严谨的人，总是很小心的对待代码，即使是在单任务软件开发过程中，我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码，尽快完善RTT！ （我的经验都来自ucos源代码，因为国外对RTOS的认证是很严格的，ucos是经过航空级认证的RTOS）
问
这里是BUG回报板块!
发布于15年前
RTT的定时计数器变量rt_tick在每个Tick中断内自增，自增到`0xffffffff`再溢出到0周而复始。 所有定时器对象的定时结束时基计算为：`timer->timeout_tick = rt_tick_get() + timer->init_tick;` 在时基中断，检查`if (rt_tick >= t->timeout_tick)`是否成立，如果成立则定时时间到。似乎很合理，但是错误就出现在这里。 如果来了20个tick的定时请求在执行`timer->timeout_tick = rt_tick_get() + timer->init_tick;`时，若`rt_tick`为`0xfffffff0`，于是得出定时结束时间为0x00000004，于是该节点加入定时器列表等待超时。结果，下一次进入中断的rt_tick为0xfffffff1，使`if (rt_tick >= t->timeout_tick)`检查成立，所以定时时间结束，错误发生了！ 这个错误平时发现不了，是因为等到rt_tick接近溢出需要很长时间（如果1毫秒一个tick的话，需要50天，10毫秒一个tick就需要500天，哈哈！），`Bernard`兄是不是考虑到这个情况才故意放过这个臭虫的呢？如果要解决该问题，必定添加不少冗余代码，影响性能。但留着这个漏洞又很不舒服，怎么办呢？
问
这里是BUG回报板块!
发布于15年前
RTT的时基函数是`rt_tick_increase()`，该函数有个不妥之处，比如我把每个线程的时间片长度设置为1个时基。 那么，有以下情况可能发生：`rt_timer_check()`函数使更高优先级的线程就绪，而该线程的时间片为1。此后`rt_thread_self()`函数返回的就是这个就绪线程，接下来紧接着时间片计数器就被减1，变为0，也就是说线程还没执行就被`rt_thread_yield()`函数当作放弃了执行对待！ 这就是不妥之处！望Bernard兄妥善解决。
问
RTT中的GBA模拟器截图
发布于15年前
偶也是小黑族的（T400-2767A82），这本本用着就不想用别的了。
TA的主页
TA的回答
TA的提问
TA的文章
TA的粉丝
TA的关注
会员统计
注册于 15年前
个人主页被 698 人浏览
回到
顶部
发布
问题
投诉
建议
问 关于RTOS中的Timer处理的建议