問題タブ [boost-interprocess]

ブースト message_queue とシリアライゼーションを一緒に使用する小さな実例を誰でも共有できますか? クラスを使用してプロセス間でデータを交換したいのですが、研究に行き詰まっています。

Windows プラットフォームで、送信側と受信側の両方が C++ で記述されている超高速 MQ メカニズムが必要です。

IPC にRCF-C++を使用した現在の実装では、Windows 名前付きパイプを介して約 20,000 メッセージ/秒でクロックを処理しています。

私はデモアプリに従ってboost::interprocess Message Queuesのパフォーマンスをテストしており、約48,000メッセージ/秒を測定していますが、これは驚くほど遅いです。このブログ投稿のコードを使用した C# )、約 150,000 メッセージ/秒を取得しました。

ブースト message_queue のパフォーマンスが非常に遅い理由と、それを改善するために何ができるかについてのアイデアはありますか?

テストを行ったところ、C ++/CLI実行可能ファイルでboost::interprocess::shared_memory_objectを問題なく作成および削除できました。C ++ / CLI dllプラグインでは、boost :: interprocess :: shared_memory_objectしか作成できませんが、削除に失敗します。削除時にファイルが存在することを確認しました。このファイルは、「20110606204418.125000」という名前のサブフォルダーのboost::interprocessフォルダーに存在します。メモリは他のプロセスによってマップされていません。原因となる可能性のあるアイデアはありますか？最初は、プロジェクトがdllであり、CLRをターゲットにしていることと関係があるのではないかと思っていましたが、正直なところわかりません。編集：削除コードは作成コードとは異なるスレッドによって呼び出されます-これは許可されていませんか？

boost::interprocess::managed_shared_memory共有メモリにデータ構造をロードするために使用します。共有メモリ セグメントを物理メモリに固定する必要があります (たとえば、マップされたファイルのシステム コール mlock に似ています)。

Linux では、遅かれ早かれデータ構造が物理メモリからスワップアウトされます。私の場合、構造がスワップアウトされた後、構造にアクセスする次のプロセスに法外なコストが発生します。

共有メモリを物理メモリに固定する方法はありますか? 使用できないことを意味する場合でも、解決策に興味がありますboost::interprocess。

私が望むのは、メモリマップされたファイルとして読み取るためにファイルを開くのは簡単です-将来的にはるかに高速にアクセスするために（例：ファイルを開いて最後まで読み取り、待ってから何度も読み取ります）その間、私はそのファイルが欲しいです他のプログラムによって変更可能になり、それを変更するときに、ifstreamも変更したいと思います。ブースト iostreams (またはブースト インタープロセス) でそのようなことを行う方法は? トールOSだけでいいですか？このファイルはすべてのアプリにメモリマップされますか？

だから私はそのようなコードを試します:

ファイルを開くか作成し、RAMに入れます。しかし、他のプログラムからはアクセスできません (編集と保存はできませんが、開くことはできます)m=( 他のプログラムからファイルを編集可能にするには?

boost::interprocess複数のプロセス間で同期を実行するために使用したい。具体的には、Linux OS で使用したいboost::interprocessnamed_mutex(私は g++ を使用しています)。

このクラスの各インスタンスを単純なように共有メモリに格納する必要があるかどうか知っていますboost::interprocess::mutexか?

次のboost::interprocess::message_queue関連の質問があります。

意図したとおり、2 つ以上のプロセス間でメッセージ キューを共有する予定です。明らかに、そのうちの 1 つがメッセージ キュー内でクラッシュする可能性があります。その結果、内部ロックが保持され、他のプロセスがキューにアクセスできなくなります。これはどのように解決できますか？使用されている内部ミューテックスをロック解除する方法はないようです。

boost::interprocess::managed_shared_memory セグメントに boost::unordered_map を作成しようとしています。これは、boost::interprocess::allocator を使用してから boost::interprocess::cached_node_allocator に変更しようとするまでは問題なく動作します。

hash_bucket 構造がキー サイズの計算を遅らせているようですが、cached_node_allocator はコンパイル時にサイズが必要です。これを機能させる方法についてのアイデアはありますか？

サンプルコード:

GCC 出力:

const std::string &を返すクラスメソッドをconst boost::interprocess::basic_string &に置き換えようとしています。私が直面している主な課題は、実装が類似しているにもかかわらず、2 つのクラス間の非互換性です。より明確な説明のために、それをコードに入れます

このクラスは次のようになります。

問題は、これに依存する巨大なコード ベースがあることです。

予想される結果を const ShMemString & に置き換えてすべてのコードを調べたとしても、その後の使用法も修正するのはさらに困難な作業になります。ブーストの文字列に std::string からの比較/構築メソッドが含まれていないことに驚きました。

これにアプローチする方法についてのアイデアはありますか?

次のようになります。

MyTypeは典型的な構造体で、my_segmentは正しく構築されています boost:: interprocess ::managed_shared_memory * は、同等のものより約 10 倍遅くなります。

私はこれを期待していませんでした。2 つの割り当てアルゴリズムは、実装とパフォーマンスが類似している必要があります。このような大きな違いには何か正当な理由があるのでしょうか。

編集：テストは膨大な回数の反復で実施されました。