常用于RTOS（VXworks）的设计模式

Question

任何人都可以帮助我了解常用于RTOS的设计模式吗？
在VXworks中，哪种模式更可取？

Answer 1

我们可以忽略你的问题，第二句？这是没有意义的，也许是对设计模式的误解。然而，第一部分很有趣。也就是说，我将其推广到覆盖实时系统而不是RTOS。

许多最熟悉的模式是机械的，但在实时系统中更高层次的架构模式也很重要。

Bruce Powell Douglass可能是对的模式进行实时系统这一主题的最重要作者。如果你想要的是什么，他不得不在随后的Embedded.com阅读this article主题说的味道（这是三个系列的第三部分，请务必仔细阅读前两个为好，因为他们还对主题触摸，(1)(2) ）。您也可以访问Embedded.com并在搜索框中输入“设计模式”，还有一些关于该主题的特定模式和一般文章的文章。

尽管我认为您对“RTOS（VxWorks）”的请求模式的要求很高，但我特别使用的VxWorks模式是Facade和Adapter模式。部分提供OO API，并提供一定级别的RTOS不可知抽象。随后为Segger emBOS实现了最终的类（以允许我们运行更小，成本更低，免版税的RTOS），并且Windows和Linux都允许在更强大的工具的更丰富的环境中测试，调试和模拟代码。设置在Wikipedia，其中许多将适用于实时系统

的非穷尽很多模式的列表。列出的并发模式最为明显。

Answer 2

正如Mike DeSimone所评论的那样，过于通用。但是，对于RTOS（不仅仅是VxWorks），要记住几件事情。

1. 避免做过多的ISR。如果可能的话，将一些处理传递给等待的任务。
2. 保持多线程最佳。太多，你有背景切换的开销。太少，你的问题解决方案可能会很复杂。

Answer 3

另一个重要方面是让RTOS保持可预测性并且可以让用户理解。通常情况下，您会看到固定优先级的调度程序不会公平或不具有适应性，而是完全按照所讲的方式执行，如果您搞砸优先级并挨饿某些任务，那就这样做吧。完成内核操作的时间往往很短并且可以预测，通常记录下它们最糟糕的执行时间。