私は、Boost Interprocess をかなり頻繁に使用するメモリ マップ ファイルに支えられたスレッド セーフ キューに取り組んでいました。私はそれをコードレビューに提出しましたが、この地球上で私よりも長い経験を持つ開発者は、boost::interprocess が「プライムタイムの準備ができている」とは感じておらず、pthreads を直接使用する必要があると述べました。
それはほとんどFUDだと思います。個人的には、upgradable_named_mutex や boost::interprocess::deque などを再実装するのはばかげているとは思いませんが、他の人がどう思うか知りたいです。彼の主張を裏付けるデータを見つけることができませんでしたが、おそらく私は知識がないか、単純なだけです. Stackoverflow 教えてください！
プロジェクトにboost::interprocessを使用しようとしましたが、複雑な気持ちになりました。私の主な不安は、boost::offset_ptr の設計と NULL 値の処理方法です。要するに、boost::interprocess は、NULL ポインターの間違いを診断するのが非常に苦痛になる可能性があります。問題は、共有メモリ セグメントがプロセスのアドレス空間の途中にマップされていることです。これは、「NULL」offset_ptr が逆参照されたときに有効なメモリ位置を指すため、アプリケーションがセグメンテーション フォールトしないことを意味します。これは、アプリケーションが最終的にクラッシュしたときに、エラーが発生してから時間がかかる可能性があることを意味し、デバッグが非常に困難になります。
しかし、それは悪化します。boost:::interprocess が内部的に使用するミューテックスと条件は、セグメントの先頭に格納されます。したがって、誤って some_null_offset_ptr->some_member に書き込みを行うと、boost::interprocess セグメントの内部機構を上書きし始め、まったく奇妙で理解しにくい動作になります。複数のプロセスを調整するコードを記述し、考えられる競合状態に対処することは、それ自体が困難になる可能性があるため、二重に腹立たしいことでした。
私は自分自身の最小限の共有メモリ ライブラリを作成し、POSIX mprotect システム コールを使用して、共有メモリ セグメントの最初のページを読み取り不能および書き込み不能にすることになりました。組み込みシステムを使用していない限り、それだけの価値があります)。boost::interprocess を使用してみることもできますが、手動で mprotect を呼び出すこともできますが、boost はセグメントの先頭に格納されている内部情報に書き込むことができると想定しているため、うまくいきません。
最後に、offset_ptr は、共有メモリ セグメント内に、同じ共有メモリ セグメント内の他のポイントへのポインタを格納していると想定しています。複数の共有メモリ セグメントを使用することがわかっている場合 (書き込み可能なセグメントが 1 つと読み取り専用のセグメントが 1 つあったため、これが当てはまることはわかっていました)、相互にポインターを格納すると、offset_ptr が邪魔になり、一連の手動変換を行う必要があります。私の共有メモリライブラリでは、あるセグメントへのポインタ、別のセグメントへのポインタなどになるテンプレート化されたSegmentPtr<i>クラスを作成しました。コンパイル時間)。SegmentPtr<0>SegmentPtr<1>
すべてを自分で実装するコストと、NULL エラーを追跡し、さまざまなセグメントへのポインターを混同する可能性があるために費やす追加のデバッグ時間とを比較検討する必要があります (後者は必ずしも問題ではありません)。私にとっては、自分で実装する価値はありましたが、boost::interprocess が提供するデータ構造をあまり利用していなかったので、明らかに価値がありました。将来、ライブラリがオープンソースになることが許可された場合 (私次第ではありません)、リンクを更新しますが、今のところ息を止めないでください;p
ただし、同僚に関しては、boost::interprocess 自体に不安定性やバグはありませんでした。その設計により、独自のコードでバグを見つけるのが難しくなっていると思います。
boost :: interprocess共有メモリとinterprocess.synchronization_mechanisms.message_queueを約6か月間使用しており、コードは信頼性が高く、安定していて、かなり使いやすいことがわかりました。
データはかなり単純な固定サイズの構造体（12個のリージョンで合計2 + GBのサイズ）に保持され、boost :: interprocessのサンプルコードをそのまま使用し、ほとんど問題はありませんでした。
boost::interprocessをwindowsで使用するときに注意すべき2つの項目が見つかりました。
#include <boost/interprocess/shared_memory_object.hpp>オブジェクトを使用する場合は、最初にWindowsを再起動することによってのみ、メモリマップ領域のサイズを増やすことができます。これは、boostがファイルバッキングストアをどのように使用するかによるものです。私は、boost::interprocessに関する彼の問題についてのJosephGarvinの投稿が有効でなかったと言っているのではありません。私たちの経験の違いは、図書館のさまざまな側面の使用に関連していると思います。私は、boost::interprocessに安定性の問題がないように見えることに同意します。