上下文切换时间 - RTOS 和处理器的角色
在确定上下文切换时间时，RTOS 起主要作用还是处理器起主要作用？这两个主要参与者在确定上下文切换时间方面所占的份额是多少？
谁能告诉我 uC/OS-II RTOS 吗？
Does the RTOS play a major role or processor play a major role in determining the time for context switch ? What is the percentage of share between these two major players in determining the context switch time .
Can anyone tell with respect to uC/OS-II RTOS ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想说两者都很重要，但实际上并不那么简单：
实际的上下文切换时间只是执行切换所需的指令周期数的问题，就像软件中的任何内容一样，它可以有效地编码，也可以不是。另一方面，在所有其他条件相同的情况下，具有较大寄存器集的处理器将需要更多指令周期来保存上下文；但拥有较大的寄存器集可能会使其他代码更加高效。
处理器还可以具有直接支持快速上下文切换的架构。例如，低级 8 位 8051 有四个重复的寄存器组；因此，上下文切换只不过是寄存器组切换（只要您的线程不超过四个），并且考虑到 Silicon Labs 以 100MIPS 生产基于 8051 的设备，这确实可能非常快！
更复杂的处理器和操作系统可能会使用 MMU 来提供线程内存保护，这是额外的上下文切换开销，但其好处可能会覆盖这一点。当然，此类处理器通常还具有高时钟速率，这会有所帮助。
总而言之，处理器速度、处理器架构、RTOS 实现的质量以及 RTOS 提供的功能都可能影响上下文切换时间。但最终，提高切换时间的最简单方法几乎肯定是提高时钟频率。
尽管拥有更多空间固然很好，但如果上下文切换时间对于任何信誉良好的 RTOS 上的项目来说是成败问题，那么您应该考虑硬件或设计的适用性。您应该致力于最大限度地减少上下文切换的设计。例如，如果 ADC 转换需要 6us，上下文切换需要 20us，那么您最好忙等待而不是使用转换完成中断；最好使用 DMA 传输来尽可能避免单个数据项上的上下文切换。
I would say both are significant, but it is not really as simple as that:
The actual context switch time is simply a matter of the number of instruction cycles required to perform the switch, like anything in software it may be coded efficiently or it may not. On the other hand, all other things being equal, a processor with a large register set will require more instruction cycles to save the context; but having a large register set may make other code far more efficient.
A processor may also have an architecture that directly supports fast context switching. For example the lowly 8bit 8051 has four duplicate register banks; so a context switch is little more that a register bank switch (so long as you have not more that four threads), and given that Silicon Labs produce 8051 based devices at 100MIPS, that could be very fast indeed!
More sophisticated processors and operating systems may use an MMU to provide thread memory protection, this is an additional context switch overhead but with benefits that may override that. Also of course such processors generally also have high clock rates which helps.
So all in all, the processor speed, the processor architecture, the quality of the RTOS implementation, and the functionality provided by the RTOS may all affect context switch time. But in the end the easiest way to improve switch time is almost certainly to increase the clock rate.
Although it is nice to have more headroom, if context switch time is a make or break issue for your project on any reputable RTOS you should consider the suitability of either your hardware or your design. You should aim toward a design that minimises context switches. For example, if an ADC conversion takes 6us and a context switch takes 20us, then you would do better to busy-wait than to use a conversion-complete interrupt; better yet use DMA transfers to avoid context switches on single data items where possible.
uC/OS-II RTOS 是用 C 语言编写的，有一些非常具体的部分（可能在汇编中）用于处理器特定的处理。上下文切换将是特定于处理器的部分的一部分。
因此，上下文切换时间很大程度上取决于所选的处理器以及用于使 uC/OS-II 适应该处理器的特定部分。我相信所有源代码都是可用的，因此您应该能够看到上下文切换需要多少源代码。我还认为 uC/OS-II 有回调，可以让您添加一些性能测量代码。
uC/OS-II RTOS is written in C, with some very specific sections(maybe in assembly) for the processor specific handling. The context switching will be part of the sections that are very specific to the processor.
So the context switch time will be very dependent on the processor selected and the specific sections used to adapt uC/OS-II to that processor. I believe all the source code is available so you should be able to see how much source is needed for a context switch. I also think uC/OS-II has callback's that may allow you to add some performance measuring code.
为了完成 Clifford 所说的，上下文切换时间还取决于触发上下文切换的条件，因此主要取决于基准测试。
根据 RTOS 的实现，在某些情况下，可以完全绕过调度程序直接切换到第一个等待进程。
这当然会给一些基准测试带来巨大的提升。
例如，我们制定了一些基准测试来测量传递信号并切换到高优先级进程所需的开销（以微秒为单位），从而改变特定的内核配置和目标架构：
http://www.bertos.org/discover/context-switch-overhead
Just to complete on what Clifford was saying, context switching time also depends on the conditions that trigger the context switch, so mainly it depends on the benchmark.
Depending on the RTOS implementation, in some cases it's possible to switch directly to the first waiting process bypassing the scheduler altogether.
This of course gives a huge boost in some benchmarks.
For example we make some benchmark that measures the overhead (in µs) required to deliver a signal and switch to the high-priority process varying the particular kernel configuration and the target architecture:
http://www.bertos.org/discover/context-switch-overhead