Boost.Interprocess の限られた経験から、大きな問題はありませんでしたが、パフォーマンスについてはコメントできません。プログラムのフォルダーの外で作成されたファイルを使用して処理を行うことは事実ですが、それらはすべてメモリ マップされている必要があり、パフォーマンスの問題のほとんどが解消されます。いずれにせよ、IPC を使用している場合は、常に追加のパフォーマンス オーバーヘッドを予期する必要があります。
あなたが強調した批判については、名前付きミューテックスまたは以前のプロセスによって横たわっている他の名前付きリソースを削除することが可能です(静的remove(const char*)
関数を参照)。公平を期すために、アプリケーションによっては、正しく使用するのが難しい場合がありますが、これは Windows API を使用するときに対処する必要はありません。一方、Windows API は移植性がありません。私の推測では、ファイルを使用して (より良い代替手段が存在する場合でも)、異なるプラットフォーム間でライブラリのインターフェイスと動作の一貫性を維持していると思われます。
とにかく、名前付きミューテックスは、ライブラリが提供するもののほんの一部です。便利な機能の 1 つは、STL アロケータを含む共有メモリ領域に独自のメモリ マネージャを提供することです。個人的には、生のメモリを使用するよりも、それが提供する高レベルの構造を使用する方が快適だと思います。
更新: Boost のドキュメントをさらに掘り下げたところ、さまざまな興味深い情報に出会いました。
このページでは、ライブラリの実装とパフォーマンスについてもう少し詳しく説明していますが、実装の根拠は含まれていません。
このリンクは、Windowsミューテックスの実装が何らかの作業(バージョン1.46)を使用できることを明確に示しています。フォルダーをもう少し掘り下げると、とboost\interprocess\sync
という名前のフォルダーがさらに 2 つあることがわかります。どちらにも、同期プリミティブの実装の詳細が含まれています。のposix実装はあなたが期待するものですが、エミュレーションの実装はかなり基本的です:posix
emulation
interprocess_mutex::lock
// Taken from Boost 1.40.
inline void interprocess_mutex::lock(void)
{
do{
boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0);
if (m_s == 1 && prev_s == 0){
break;
}
// relinquish current timeslice
detail::thread_yield();
}while (true);
}
一見すると、彼らは Posix のサポートを目指し、それ以外のすべてをメモリ マップ ファイルを使用するエミュレーション レイヤーにまとめました。彼らが特別な Windows 実装を提供しない理由を知りたい場合は、Boost メーリング リストに質問することをお勧めします (ドキュメントには何も見つかりませんでした)。