0

現在の投稿タイトルがそれについて述べているように、ブースト boost::interprocess::interprocess_condition::wait は、待機中にミューテックスをアトミックにロック解除することを想定していますが、そうではありません。

次のコードでは:

boost::interprocess::scoped_lock< boost::interprocess::interprocess_mutex > state_access_lock(impl->state->state_access_mut);
impl->state->state_access_cond.wait(state_access_lock);

VS2010 でデバッグ モードに入ると、一時停止を押して、待機中に state_access_lock がまだロックされていることに驚きました。

しかし、それはブーストのドキュメントがここで言っていることではありません。

誰か提案がありますか？

ありがとう。

4

2 に答える 2

0

これまでのコメントに基づいて、答えを推測できると思います。

interprocess_condition::wait() に渡す scoped_lock のメンバーを信頼しないでください。(interprocess_condition_any とは異なり) interprocess_condition のコントラクトは、interprocess_mutex のロックでのみ使用できると述べています。これを知っている条件変数は、ロックについて何も知らない場合よりも効率的にジョブを実行するために、ロックから内部ミューテックスを引き出します。

そのため、ミューテックスのロックを解除する場合は、scoped_lock で unlock() を呼び出すのではなく、ミューテックスで直接呼び出します。これは、内部実装では問題ありません。家でこれをしないでください。ロックが範囲外になる前にミューテックスを再ロックしないと、悪いことが起こります。

つまり、デバッガーに表示される動作は、問題を示すものではありません。デッドロックがある場合は、別の場所にある必要があります。

編集

与えられた実際のコードの条件変数のものは、私にはうまく見えます。start_mut とのやり取りが少し奇妙だと思います。その部分は問題ないと確信していますか？

于 2013-06-14T09:51:04.693 に答える