timer问题

发布于 2009-12-05 11:58:33 浏览：3360 订阅该版

2 个回答

bernard 2009-12-05

这家伙很懒，什么也没写！

>近段时间看了下代码，这个同优先级的任务切换（时间片）是通过每个任务挂一个定时器到定时器模块，但是呢这个定时也开放给应用程序使用，而且任务也有可能实时创建和销毁，作为实时系统，执行时间确定性肯定会有问题，

---

这个定时器并不是完全开放的，但所有源代码都开放，用户可以完全从头改到尾，只能说一个逻辑上的不开放。这个定时器是内置在线程的TCB里，确定性能有什么问题呢？可能楼主把线程内建的定时器和一般的定时器混淆了。

>还有个致命的问题，就是应用程序挂到定时器的执行函数的稳定性和运行时间不确定，个人认为操作系统内核应该有很强的健壮性，应用程序能影响内核的渠道应该尽量杜绝，

---

RTOS一般都没有完全属于自己的内存保护空间，所以一个好的系统不仅内核要好，在上面编写代码的程序员也要时刻注意，是否会影响到系统的性能（最明显的一点，如果程序员用户把中断给永远关闭了，那么系统就成为一个和OS彻底无关联的系统）。做为实时内核，只能保证和系统紧密相关的服务不会影响到实时性。至于挂接定时器函数的运行时间，这个确实是不确定的，这个序列的时间确定性很难保证的，因为它是一个查找过程，目前还不存在时间确定的查找算法。oldtom有一个软定时器的补丁（原来是为ucos-ii而写的），目前还在评审过程中，应该不久会更新到服务器上。

实时系统是一个很大的话题了，详细可以看看 RT-Thread编程指南 开始章节的介绍。这里则着重说明一点，一个实时系统都是针对某一或某些事件的实时响应，而很难做到对所有事件的实时响应（想想为什么）。所以要实现一个实时系统，首先要考虑的是，哪些是实时事件，哪些是非实时事件。实时事件是不可延误的，需要对这些事件进行着重考虑。例如，一个采用AD采集数据进行相应控制的系统，AD数据采集是实时事件。而一些显示状态用的工作则可通过把优先级调低的方式把系统优先供给AD采集使用。如果显示状态使用到了定时器，那么就可以把定时器制作成软定时器的方式来减少对系统的影响。

>另外我觉得这个系统应该把中断管理加入到内核，如ecos或者CE那样，中断分ISR和DSR，尽量把中断处理抽象出来，这个给开发移植更大的好处及方便，呵呵，我也是菜鸟，想到那说到那，欢迎大侠们拍砖

---

关于中断部分，还请仔细看看 RT-Thread编程指南 文档，里面有详细的底半中断描述，以及在RT-Thread中如何编写代码实现底半模式编程。