时钟节拍处理是不是每次都要切换任务？

void_c

时钟节拍处理是不是每次都要切换任务？

1.时钟节拍处理，只有新任务就绪，才切换任务。
2.时钟节拍处理，不管是否有新任务就绪，都切换任务。

信号量释放也有类似，

1.信号量释放时，只有新任务就绪，才切换任务。
2.信号量释放时，不管是否有新任务就绪，都切换任务。

该选哪种方法？

ralfak

时钟节拍选择1，不过时钟节拍中断一般都是手动保护现场。

信号量从任务释放时，应该是检查是否有更高优先级的任务才切换，或者是当前任务阻塞了，不切换意味着不需要保护任务环境。
信号量从中断释放时，有一个是否需要调度的标志位，
上述是freertos的做法，总之就是有需求才干。

ffxz

RT-Thread的做法：
1.
时钟节拍，检查是否有线程超时，如果超时把线程放到就绪队列中，并做一次重调度

重调度并不意味着一定切换到其他任务去，只有当发现有任务比当前任务优先级更高才切换过去

如果在中断ISR中进行重调度，那么设置一个标志位，在ISR返回时检查标志位，如果标志位置位则做切换动作，否则不做。

2.
信号量的情况，释放时，如果有线程等待于这个信号量，将把它唤醒并放到就绪队列中，然后做一次重调度。

ralfak

RT-thread 最高优先级采用的位图查表方式计算，这点与UCOS一致啊，呵呵

ffxz

否则如何做到实时啊，不查表，时间是不确定的。

已经在考虑STM32用新的方式了，直接用它指令的优势来提高操作系统的性能；另外一个改变，就是计划在操作系统中变成永远不关中断的（不过这点还没最后确定下来，主要还得考虑各个平台的一致性）。

ralfak

实时也是有一个指标啊，最好情况和最坏情况。
查表是挺方便，就是一个优先级只能安排一个任务，而且没办法时间片吧。

ffxz

查表后就是，最好情况 = 最坏情况，线程调度完全确定化了，和线程数的多少无关

呵呵，RT-Thread是支持多个相同优先级线程存在的，相同优先级线程调度就演变成时间片了。好在每个线程的时间片长度都是可以自己设置的，这样也可以在相同优先级线程中设置各个线程占用的百分比。

ffxz

正是在这一系列的保证下，RT-Thread才可能达到接近一些商业化RTOS的性能水平。