問題タブ [boost-mutex]

scoped_lock で timed_mutex の両方を使用しようとしています。以前、いくつかの例に従って scoped_lock を正常に使用したことがありますが、今ではうまくいかないようで、ブーストのドキュメントを正しく理解することもできません。

望ましい動作は次のとおりです: scoped_lock の取得を x 時間試行し、成功した場合は true を返し、それ以外の場合は false を返します。

現在私は持っています：

ただし、このscoped_lockがブール値を返すかどうかを（ブーストのドキュメントまたは例を介して）見つけようとすると、何も見つからないか、実際に異なる方法が見つかります。

したがって、私はそれを行う正しい方法は何か、それはどのように正確に機能するのか、そしてブーストのドキュメントをどのように正しく「読む」かについてのいくつかの指示を尋ねます.

アップデート：

そう

scoped_lock.owns_lock() でロックしようとすると、10 ミリ秒 (この場合) の間にロックを取得しようとし、時間切れでロックが取得されなかった場合に false を返すミューテックスを作成しますか?

Boost Synchronizationに関するドキュメントを調べましたが、 aboost::unique_lockが順番にロックを達成するかどうかを判断できないようです。

つまり、2 つのスレッドが既にロックされているミューテックスをロックしようとして競合している場合、ロックが解除された後、ロックしようとする順序は維持されますか?

マルチプロセッシング同期のためのポータブルで堅牢なソリューションを長い間探していました。これに触れた人は、良い解決策が boost::iterprocess という名前の同期オブジェクトであることを知っています。しかし....プロセスがnamed_mutexをロックし、プロセスが停止した場合（バグやその他だけでなく、プロセスが停止する通常の状況はたくさんあります。）その場合、named_mutexはロックされた状態のままになります。Ion Gaztanaga (www.boost.org/doc/libs/1_55_0/boost/interprocess/detail/robust_emulation.hpp)によって行われたブースト コードで、robust_mutex を作成する試みがありました。

彼は、状態チェックの放棄をどのように解決するかについて良い考えを持っていました。ゲーム内の各プロセスには独自のロック ファイルがあり、実行中はそのファイルをロックしたままにします。その後、Ion のrobust_mutex チェックは、ロック試行が失敗した場合、現在の所有者がロック ファイルを処理し、現在のミューテックス所有者が生きているかどうかを判断できます。デスミューテックスの場合は取得できます。ファイルロックのトリックは、プロセスが停止した場合にファイルロックがOSによってロック解除されるため、良いアイデアであり、これは移植性が高いようです。このソリューションは、ベースの spin_mutex をラップし、現在の所有者のプロセス ID を内部フィールドに保持します。徹底的なテストを行ったところ、2 つの大きな問題が見つかりました。

1. ファイル ロックの処理と実装方法は、ファイル ロックを使用するだけで高速になるようにミューテックスを遅くします。

2. 有効なロック ゲート変数と所有者プロセス ID を分離すると、異なるプロセスによってミューテックスが盗まれる状況が発生します。

そして、ここに私の質問があります: 私は両方の問題の解決策を提案しています。

1. 既存のプロセスごとに個別のロック ファイルを使用するのではなく、すべての最終的なプロセス ID (十分な 4MB があるはずです) に対して 1 つのファイルを使用し、各プロセス ロックに対して 1 バイトのみを使用します。そのバイトの位置は、プロセス ID 自体によって決定されます。(これは私の考えではありませんが、Howard Chu と彼の優れた LMDBのコードで見つけました)

2. spin_mutex をそのままラップするのではなく、コードを書き直して、0/1 の代わりに現在の所有者のプロセス ID をロック ゲートとして使用するようにします。これにより、ロックとロック解除を 1 つのアトミック CAS 操作で行うことができます。

私はそれを実装しようとし、Windowsでテストしました。オリジナルのブースト コードを使用し、必要に応じてブーストを呼び出します。ここにコードがあります。これはプロジェクト ツリーから取得したものなので、テストしたい場合は、一部のインクルードを調整する必要があります。これは提案なので、コード スタイルなどについて私を責めないでください。アイデアやモードが良ければ、どんどん完成させていきます。そうでない場合は、何か他のものを使用しますが、他に何も見つかりません。

recursive_mutex と named_mutex のバージョンもあります。次に、ある種の修正提案があります。これは、あるプロセスが以前に放棄されたミューテックスの所有権を取得した場合、何らかの整合性チェックを行う必要がある可能性が高いからです。

最終的な改善について話し合いたい

前もって感謝します

ラディスラフ。

子プロセスから c++ の同期キューを消費しようとしています。この同期キューを C++ で使用しています () ( http://www.internetmosquito.com/2011/04/making-thread-safe-queue-in-ci.html )

ブーストでシリアル化できるようにキューを変更し、boost::mutex io_mutex_代わりに使用していたプロセス間ミューテックスを置き換えました（@Seheに感謝します）boost::interprocess::interprocess_mutex io_mutex_そして、ロックするときに、必要なすべての行を変更boost::mutex::scoped_lock lock(io_mutex_);しましたscoped_lock<interprocess_mutex> lock(io_mutex_);

}

私のテスト アプリでは、同期キューを作成し、このクラスの 100 個のインスタンスを格納しています。

消費者と生産者の間の一般的な定義:

プロデューサー プロセス コード:

私の消費者コードは次のとおりです。

キューを作成し、子 (コンシューマー) プロセスを作成する親プロセス (プロデューサー) を実行すると、キューから「ポップ」しようとすると子がクラッシュします。

ここで何が間違っていますか？何か案が ？洞察をありがとう。これは、ブーストと共有メモリを使用して作成する最初のアプリです。

私の目標は、複数のプロセスからこのキューを消費できるようにすることです。上記の例では、他の子プロセスを作成する前に最初に動作することを確認するために、子プロセスを 1 つだけ作成しています。アイデアは、キューがアイテムによって事前に満たされ、複数の作成されたプロセスが互いに衝突することなくアイテムを「ポップ」することです。

クラスでは、このような関数に対してミューテックスを使用したい

コンパイル プロセスに問題はありません。しかし、プログラムを実行すると、次の行でブーストが常に失敗します。

lock()orunlockメソッドを使用しようとしましたが、同じ問題です。私が使用するときtry_lock、条件は常に false で失敗しません。

インターネットで検索すると、このhttps://svn.boost.org/trac/boost/ticket/9307が見つかりました。

しかし、問題は私のプログラムだと思いますが、どこにあるのかわかりません。私のテストでは、この関数に入るスレッドは 1 つだけです。

コード内のブースト依存関係の一部を取り除き、代わりに新しい C++11 機能 (Visual Studio 2013) を使用しようとしています。

boost::mutex一緒に使用したコンポーネントの 1 つで、boost::lock_guard<boost::mutex>すべてが正常に機能しました。std::mutex代わりにwithを使用するとstd::lock_guard<std::mutex>、 から戻るときに次のエラーが発生しますmain()。

GrabberTester.exe の 0x7721E3BE (ntdll.dll) で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0xA6A6B491。

実際のプロジェクトは非常に複雑であるため、この問題を再現するために完全に機能するコード例を提供することは困難です。私の実際のプロジェクトでは、実行時にロードされる共有ライブラリでミューテックスが使用されます（ただし、から戻るまでにアンロードされているはずですmain()）。

私の質問は次のとおりです。

• と はまったく同じように動作するように設計されていますboost::mutexか?std::mutex
• そうでない場合、違いは何ですか？std::mutexの代わりに使用する場合、何に注意する必要がありboost::mutexますか?
• 共有ライブラリでは、boost::threadフレームワークでスレッドを作成しています。std::mutexは sでのみ使用でき、sstd::threadとは互換性がないboost::threadのでしょうか?

編集：

もう 1 つ気付きました。動的にロードされた共有ライブラリをアンロードすると、時間がかかります。(DLL はハードウェアにアクセスし、すべてを完全にシャットダウンするには時間がかかります)。ただし、に切り替えるとstd::mutex、DLL をすぐにアンロードできるように見えますが、から戻るとプログラムがクラッシュしmain()ます。std::mutex問題は特に DLL のコンテキストにあるという印象があります。

編集2：

アプリケーションと DLL の両方が、v120 ツールセットを使用してデバッグ構成で新たにビルドされ、ランタイム ライブラリ (/MTd) に静的にリンクされます。

編集3：

以下にコールスタックがあります。例外は、ドライバーのどこかから発生しているようです。偶然、私が使用しているミューテックスの実装に関係があることがわかりました。

編集4：

おそらく、これは OpenNI2 SDK のバグであり、これらの非常に特定の条件下でのみ観察できます。そこで、この質問に openni タグを追加しました。しかし、それでも疑問が残ります: なぜそれは動作するのに動作しboost::mutexないのstd::mutexですか?

デバイスからデータをキャプチャするスレッドがあります。GUIからスレッドを開始/停止します。現在、スレッドは appcontext 内のboolメンバー を定期的にチェックしています。isCapturingEnabledこのメンバーを GUI から切り替えてbool、スレッドを停止します。

これは、ミューテックスを使用する必要がある場合ですか? キャプチャ スレッドとメイン スレッドがbool同時に書き込みと読み取りを試みる可能性があるためです。