c++ - RTOS（VXworks）で一般的に使用されるデザインパターン

Question

RTOSで一般的に使用されるデザインパターンについて誰かが私を助けてくれますか？
VXworksでは、どちらのパターンがより好ましいですか？

Answer 1

質問の2番目の文を無視できますか？それは無意味であり、おそらくデザインパターンの誤解を示しています。ただし、最初の部分は興味深いものです。そうは言っても、RTOSではなくリアルタイムシステムをカバーするように一般化したいと思います。

最もよく知られているパターンの多くは機械的ですが、リアルタイムシステムでは、より高レベルのアーキテクチャパターンも重要です。

Bruce Powell Douglassは、おそらくリアルタイムシステムのパターンに関する第一人者です。彼が主題について言わなければならないことのフレーバーが必要な場合は、Embedded.comでこの記事を読んでください（これは3つのシリーズのパート3です。最初の2つも読んでください。彼らも主題に触れているからです。 、（1）（2））。Embedded.comにアクセスして検索ボックスに「デザインパターン」と入力するよりも最悪の場合もあります。特定のパターンに関する記事や、このテーマに関する一般的な記事が多数あります。

「RTOS（VxWorks）」のパターンをリクエストするのはかなり具体的だと思いますが、私がVxWorksで特に使用したパターンは、ファサードとアダプターのパターンです。部分的にはオブジェクト指向APIを提供し、またRTOSにとらわれない抽象化のレベルを提供するためです。結果として得られたクラスは、Segger emBOS（より小さく、低コストで、ロイヤリティフリーのRTOSを実行できるようにするため）、およびWindowsとLinuxの両方に実装され、より強力なツールを使用して、よりリッチな環境でコードのテスト、デバッグ、シミュレーションを実行できるようになりました。

多くのパターンの網羅的ではないリストがウィキペディアで提供されており、その多くはリアルタイムシステムに適用できます。リストされている並行性パターンは、最も明らかに関連性があります。

Answer 2

Mike DeSimoneがコメントしたように、あまりにも一般的すぎます。ただし、RTOS（VxWorksだけでなく）について留意すべき点がいくつかあります。

1. ISRでやりすぎないようにしてください。可能であれば、処理の一部を待機中のタスクに渡します。
2. マルチスレッドを最適に保ちます。多すぎると、コンテキスト切り替えのオーバーヘッドが発生します。少なすぎると、問題の解決が複雑になる可能性があります。

Answer 3

もう1つの重要な側面は、RTOSをユーザーが予測可能で理解しやすい状態に保つことです。通常、公平または適応しようとはせず、指示どおりに実行する固定優先度のスケジューラーが表示されます。優先度を台無しにしてタスクが不足している場合は、そうしてください。カーネル操作を完了するまでの時間は短く予測可能である傾向があり、多くの場合、最悪の場合の実行時間で文書化されます。