4

私は現在、Linux での epoll および他のプラットフォームでの同等のテクノロジを中心に設計された、かなり大規模なシングルスレッドのイベントベースのアプリケーションに取り組んでいます。現在、2 つのインスタンスを通信させたい場合は、通常、同じマシン上で実行されているかどうかに関係なく、ソケットを介して行われます。パフォーマンス上の理由から、同じマシンの通信を高速化するために何らかの形の IPC を使用することを想定しています。ここで、どの IPC メカニズムを使用するかを決定する必要があります。

私にとって重要な要素は次のとおりです。

  • 完全な再設計なしのイベント駆動型 -- IPC メカニズムが epoll にうまく適合しない場合、それは私にとって何ヶ月もの作業が失われることになります
  • 高速 -- このメカニズムがソケットよりも高速でない場合、時間をかけて実装する価値はありません
  • 柔軟で、実行中に (再) 構成可能 -- これにより、MPI などを排除できると思います。
  • マルチスレッドは必要ありません。

すべてが同じパラダイムを使用している限り、プラットフォームごとに異なるメカニズムを使用したいと考えています。また、プラットフォーム固有のバインディングのために、C / C++ / Obj-C についても必要なだけ深く掘り下げたいと思っています。

なにか提案を？

ありがとう。

4

3 に答える 3

3

Unixソケット。名前付きパイプ。FIFO。

これらはすべて同じ基本機能を提供します-同じマシンクロスプロセス通信。ただし、実装はわずかに異なる動作を提供します。

それらはすべてファイル記述子を使用するため、文字通り、ソケットがあった場所にプラグインするだけで済みます。

于 2010-12-06T10:52:01.183 に答える
2

実際、skwllsp が述べたように、AF_INET ソケットはローカル ホストでのデータ転送用に最適化されており、速度と複雑さは fifos、pipes、unix ソケットと同等 (ほぼ同じ?) です (宛先が同じホスト）。私の 2 セントは、ソケットを使用することです。この方法では、IPC メカニズムに対して同じインターフェイスを維持するだけでなく、リモート シナリオとローカル シナリオの両方でコードを正常に再利用できます。

于 2010-12-06T13:05:59.663 に答える
0

Unix SysV IPC を試してみてください。それはサポートします:-

  • メッセージ待ち行列
  • セマフォ
  • 共有メモリ

それはあなたを助けるかもしれません。

このリンクはさらに役立つかもしれません: http://www.ibm.com/developerworks/aix/library/au-ipc/index.html

于 2010-12-09T08:54:11.840 に答える