タグ付けされた質問 「message-passing」

私の質問は、いくぶん教育されていない視点から来ています。 「メッセージパッシング」システムと「イベントベース」システムの相対的なメリットは何ですか。 なぜ一方が他方を選択するのですか？彼らの長所と短所は何ですか？ 「理論的に」だけでなく、「実際に」も知りたいです。 編集： 特定の問題： 小規模なサービスとして動作するプラグ可能なコンポーネントのシステムを構築したい（それぞれが小さなタスクを実行したり、情報を提供したりする）。 サービスは次のことができます。 1つのサービスの出力が別のサービスへの入力の1つとして機能できるように階層化される 前の文で述べたように、特定の入出力関係がなくても1つのサービスを別のサービスに含めることができるように、包含階層があります。 システムの目標は、別のシステムの低レベルイベントの単一のフローを高レベルの情報と機能に変換し、さらに単一のイベントを提供する他のシステムへのチャネルを提供することです。 これで十分でない場合、詳細を提供できます。 もう少し見て回った後。これとこれはおそらく、より良い私の状況を説明しています。 これは私の状況に適しているようです：http : //akka.io/

27 event-programming  message-passing 

複数のプロセッサを備えたベアメタルまたは最小限のRTOSタイプの組み込みシステムで、メッセージパッシングインターフェース（MPI）を使用して同一のプログラムを各プロセッサで実行し、ロードバランシングとプロセッサ障害時の冗長性を提供することは可能ですか？渡されたメッセージに基づいて他のCPUが実行するアクションを変更するステートマシンなど。たとえば、ロードバランシングまたは定期的なアライブメッセージの送信のためにシステムループの一部を引き継ぐように別のプロセッサに要求し、各CPUが何を担当しているかを記憶するCPUの冗長性。 この例の図では、「オープン」である完全なシステムループの実際の部分は、異なるシステムである可能性があります。ある種の非常に原始的な非対称マルチプロセッシングで、各CPUで実行されている完全なシステムループの一部を開いたり閉じたりする機能だけでは、協力がありません。別のCPUへの「プロセスの移行」は、別のCPUがシステムループのその部分を開くように要求することによってトリガーされます。その後、要求側のCPUがその部分を閉じるか、クエリが実行されたときに別のCPUからの応答がないため、一定時間存続する。 組み込みOSを移植してカスタムボードで対称または非対称のマルチプロセッシングを実際に実行することはできず、理論的には可能であるように思えますが、設計が非常に悪いため、これは潜在的なプロセッサ障害の解決策およびロードバランシングの解決策として提案されています考え。また、この方法でメッセージパッシングを使用するための設計パターンやアルゴリズムを見つけることができませんでした。 ソフトウェアエンジニアリングの決定に重要な背景：学生のCubeSatプロジェクト（採点またはクラス用ではありません）。オペレーティングシステムの設計に関する知識がほとんどまたはまったくない、ほとんどが中学生の小規模なソフトウェア開発チームがあります。さまざまな理由により、私が読んだ多くの現実的な解決策のいずれも実行できません。これは、チームが対処するのに複雑すぎるほど導入される可能性があるように聞こえるかもしれませんが、それが可能であっても、CubeSatを軌道に乗る岩石に変えるいくつかの問題につながる恐ろしい設計を引き起こす可能性があるようです。 スペースフェアリングに十分な信頼性のある方法でメッセージパッシングを実装できるかどうかさえわかりません。小さなOSまたはベアのバスでメッセージを渡すために使用できるプロダクション対応の通信プロトコルを見つけることもできませんでした。私たちが必要とするような金属。しかし、私は、プロセスの移行、CPUの冗長性、およびロードバランシングのためのこの提案されたソリューションが、安全性が重要なシステムでも実行可能かどうかを知りたいと思っています。検出が困難なスリープ状態から復帰すると、2つのCPUが同じ「プロセス」またはプログラムループの一部を実行している状態になる可能性があります。

8 embedded-systems  message-passing  space-technology