关于使用虚拟机管理程序与 Windows/Linux 并行运行实时操作系统的建议
您对使用虚拟机管理程序有什么建议/经验（例如 RTS 实时虚拟机管理程序) 与非实时操作系统并行运行 RTOS。 对性能有影响吗？ 是否存在任何风险？ （比如如何确保非实时操作系统不会干扰 RTOS 的实时方面）
据我了解，必须使用双核（或超线程）CPU，以便您可以为每个操作系统分配其自己的核心。
What are your advice/experience of using a hypervisor (e.g. RTS Real-Time Hypervisor) to run an RTOS in parallel with a non real time OS. Are there any performance implications? Are there any risks involved? (like how can you ensure that the non-real time OS will not interfere with the real time aspects of the RTOS)
From what I understand, a dual core (or hyperthreading) CPU has to be used so that you can assign each OS its own core.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
主要思想是拥有一个 RTOS，它使用自己的 API 执行专门为此操作系统编写的任务。 这些任务按字符串优先级设置，其中较高优先级的任务将始终优先于较低优先级的任务。 仅当没有其他任务可运行时，优先级最低的任务才会执行（也就是说，它们都在等待某个事件，无论是超时还是外部信号）。
这一切就像通常的多任务操作系统调度程序一样，它不需要多核或硬件线程； 只是时间保证完全不同，可用的 API 反映了这一事实。
在这些混合实现中，有一个最低级别的任务运行完整的非 RT 操作系统内核，通常是 Linux 或其他一些类似 UNIX 的内核（我不知道 Windows，但应该工作相同）。 如今，我们将这种架构称为虚拟机管理程序。
因此，由于整个非 RT 操作系统作为最低优先级任务运行，因此它根本无法保证获得处理时间。 任何 RT 任务都可以随时中断它，即使是在访问硬件时也是如此。 为了保持这一点，RT 任务通常对硬件的访问非常有限，或者在非常低的级别上进行最少的仲裁。 即：可以中断磁盘访问（可能导致访问错误）； 但不是 PCI 访问（只要是短暂的且有时间限制的），
Linux 调度程序现在也有一些软 RT 扩展； 但时序保证并不像一些考虑到这一点而构建的硬 RT 操作系统那么严格。
The main idea is to have one RTOS, which executes tasks written specifically for this OS, using it's own API. These tasks are set in string priority levels, where a higher priority task will allways take precedence over a lower priority one. The lowest priority tasks will execute only as long as there's no other task available to run (that is, they're all waiting for some event, either a timeout or an external signal).
all this is just like a usual multitasking OS scheduler, it doesn't need multple cores or hardware threads; it's just that the timing guarantees are radically different, and the available API reflects this fact.
In those hybrid implementations, there's a single lowest-level task that runs a full non-RT OS kernel, usually Linux or some other unix-like kernel (i don't know about windows, but should work the same). Nowadays, we call this architecture a hypervisor.
so, since the whole non-RT OS is run as the lowest-priority task, it doesn't have any guarantee of getting processing time at all. any RT task can interrupt it at any time, even when accessing hardware. to keep this, usually the RT tasks have very limited access to the hardware, or there are minimal arbitrations at very low level. ie: can interrupt a disk access (possibly resulting in a access error); but not a PCI access (as long as are short-lived and time-bounded)
there's also some soft-RT extensions to the Linux scheduler for some time now; but the timing guarantees aren't so tight as some hard-RT OSes built with that in mind.