[Raw-OS] 关于rtx的运行效率问题

rtx有一个很致命的问题就是运行效率问题。rtx在中断里面每调用一次信号量或者事件或者mail box 等系统函数，都会往一个缓冲区里面压，然后触发pending,然后在pending里面取得这个缓冲区里面存的数，然后出pending切换到任务中去。 这个逻辑看起来无可厚非，我们来研究一下触发这个逻辑所需要的时间。rtx在中断里面触发一次事件也就是说压缓冲区以及触发pending的时间 在100MHZ的cpu上假设为0.5us，进入penging后需要压寄存器，这个时间加上取数据的时间，算他0.8us时间。也就是说比起普通的rtos来说这个过程多了0.5us + 0.8us = 1.3us的时间。普通架构的rtos响应中断后直接会在中断内执行内核函数，不会有额外的开销。 这样会带来一个严重的cpu执行效率问题，假设系统中有一个50us频率的中断，或者更短时间的中断，每一次执行都会调用内核函数从而带来消耗1.3us的额外时间，这样一来。基本上这个架构就被打残废了，相比普通中断架构的rtos运行效率会非常的底下。事实上系统中会有很多的中断执行内核函数，所以这个运行效率会很差。 每一种架构都会有其所在的缺点，并不是神一般的存在。 翻阅threadx的网站找到了两种中断架构的os的比较，这个深度的文章应该是threadx作者写的，应该能充分说明问题了。rtx 属于 Segmented Interrupt Architecture 这种架构。欢迎拍砖。 http://rtos.com/articles/18835 本帖最后由 jorya_txj 于 2015-9-8 15:23 编辑

菜鸟来给txj顶贴。

RTX是一个实时OS,在用户中断函数中调用OS函数必定会切换任务
RTX是一个为CM设计的不关中断的OS,运用了CM的先进特性避免任务间的并发

用户能在中断中使用的OS函数是有限的.且只有3个是写操作,如:
isr_evt_set,
isr_sem_send,
isr_mbx_send

且同样有另外3个相同功能函数供任务使用,如:
os_evt_set,
os_sem_send,
os_mbx_send,
任务用的这3个函数运行在特权级(经SVC调用),由于RTX是不关中断的,所以这3个函数随时可能被中断
而在用户中断中又调用了另外3个对应的函数,如果isr函数直接写操作的话就出现了经典的并发问题

举例:任务A等待0x0011事件,任务B会择机设置任务A的0x0001事件,某用户中断设置任务A的0x0010事件,如果刚好在
任务B执行os_evt_set期间的p_tcb->events |= 0x0001 语句发生用户中断,如果isr_evt_set直接设置
p_tcb->events |= 0x0010的话,当中断返回,p_tcb->events |= 0x0010设置是无效的.也就意味着丢失了一个重要的信号,
对于应用是致命的,一般结构的OS选择关中断避免此类并发.

但是聪明的RTX在isr函数中并没有直接写操作,而是将参数入队,然后悬起PendSV,用户中断返回后继续执行刚才被中断的os_evt_set函数
os_evt_set函数返回时由于咬尾中断特性CPU转而运行PendSV,在PendSV中检查是否需要处理队列.这样就保证了os_evt_set与isr_evt_set
的执行是串行化的.

只有"精妙绝伦"4个字才能形容RTX的这个设计,

RTX是一个绝对可靠的OS,永不关中断,用户的任何中断都能立即得到响应.ARM官网说到"您可以信心十足的将RTX用于您的产品设计中"

答非所问。

你都不知道用户中断函数调用RTX的isr_evt_set函数为什么要悬起PendSV,因为RTX是实时OS(既然中断中要设置事件,有可能高优先级的任务需要运行),中断函数必定切换任务,而你却说切换任务的过程是浪费时间. 你那个50us举例貌似你都不懂OS的应用. 还大言不惭的说打残废! 都不想说你 你不懂CM基本可以肯定了 真搞不懂你哪里来的信心做LPC4357开发板,好好玩你的2410吧! 本帖最后由 samos2011 于 2015-9-10 10:06 编辑

你的ARMv5版OS其实做的挺好的,不要滥竽充数的说支持ARMv7-M.

http://rtos.com/articles/18835 先把threadx 作者写的文章好好看一下，希望你能看的懂中断架构。理解了之后再来讨论。乱喷没啥意义。 本帖最后由 jorya_txj 于 2015-9-10 11:42 编辑