2

これは、この状況でのメッセージキューと共有メモリの適用性または適合性に関するものです。

  1. 複数のDLLまたは共有ライブラリ

  2. 各ライブラリは、メインアプリケーションのDLLまたは共有ライブラリとの通信を試みます。たとえば、すべてのDLLまたは共有ライブラリからのI/PおよびO/Pは、メインアプリケーションの共有ライブラリを介して通信されます。これらの通信は非同期です。

  3. アプリケーションの.so以外の一部のDLLまたは共有ライブラリは、複数のスレッドを作成します。そのような各スレッドからの出力は、アプリケーションライブラリに伝達する必要があります。これらのスレッドからの出力は再び非同期です。

  4. 私のメインアプリケーションDLL/.soは、ネットワークを介してサーバーと通信し、それに応じて応答する可能性が非常に高い他の作業を続行します

  5. 他のすべてのDLL/.soの機能は非同期です

Q-1：上記の状況で最適なのはどれですか？（I）メッセージキュー、（II）共有メモリ？

Q-2：共有メモリを使用して複数の共有ライブラリ間の同期を強制する参照またはリンクはありますか？

4

2 に答える 2

1

問題の理解が間違っていると思います：

  • 共有メモリは、ソケット、パイプ、または通常のメモリなど、さまざまなプロセスを接続するための「チャネル」です。
  • メッセージ キューは、TCP やリング バッファなど、メッセージを渡すための「プロトコル」です。ソケット (0MQ など) を介して作成するか、共有または「通常の」メモリで同期キュー (Intel TBB など、以下を参照) を使用して作成できます。

指定した仕様では共有メモリは必要ありません。共有メモリは、次のいずれかに該当する場合に役立ちます。

  • 複数のプロセスがあります (そうではありません。すべての so/dll が同じメモリを共有します)。
  • プロセスがクラッシュした場合は、プロセスのメモリを永続化する必要があります (必要になる場合がありますが、言及していません)。

ここで、コードが対話するためのプロトコルを選択する必要があります。Intel Thread Building Blocks ( TBB、Q2 に回答します) を使用することをお勧めします。それらは、あなたが達成したいことに対してさまざまな抽象化のレイヤーを提供します。私はあなたのために選択するのに十分なことを知りませんが、（長い）ドキュメントを読むのに時間がかかります.

于 2012-11-23T14:32:15.443 に答える
0

私はあなたのアプリケーションを最も一般的な意味でしか理解していないという警告がありますが、渡すメッセージが制限されており、キューが一緒にいるのに適している場合、メッセージキューは簡単だと思います。

あなたが関心を持っていると思われる 2 つの主な事柄は、同期と非同期性です。(1) POSIX メッセージ キューには、キュー同期が既に組み込まれています。これで大きな頭痛の種が 1 つ取り除かれました。select(2) Linux では、キュー ID mqd_t はファイル記述子であり、ステートメントで使用できることを意味します。これにより、非同期の問題が処理されます。メイン DLL で、すべてのキューの mqd_t 記述子をロードできます。select一貫性のある、デバッグされた、十分に理解されたメカニズムを使用して、到着した DLL メッセージをステートメントおよび処理します。(3) 共有メモリと比較して失われるわずかな効率 (そしてほとんどのアプリではごくわずか) は、msg キューの使用が比較的容易であることと、メイン アプリケーションの DLL が比較的とにかく、サーバーとのネットワーク I/O を長時間待機します。

于 2012-11-23T16:19:23.610 に答える