問題タブ [recursive-mutex]

POSIX では、mutex を再帰的にすることができます。これは、同じスレッドが同じミューテックスを 2 回ロックでき、デッドロックしないことを意味します。もちろん、ロックを 2 回解除する必要もあります。そうしないと、他のスレッドがミューテックスを取得できません。pthread をサポートするすべてのシステムが再帰的ミューテックスもサポートしているわけではありませんが、POSIX に準拠したい場合は、 .

他の API (より高レベルの API) も通常、ロックと呼ばれることが多いミューテックスを提供します。一部のシステム/言語 (Cocoa Objective-C など) は、再帰的ミューテックスと非再帰的ミューテックスの両方を提供します。一部の言語では、どちらか一方しか提供されません。たとえば、Java のミューテックスは常に再帰的です (同じスレッドが同じオブジェクトに対して 2 回「同期」する場合があります)。それらが提供する他のスレッド機能によっては、再帰的ミューテックスがなくても問題ないかもしれません。なぜなら、再帰的ミューテックスは自分で簡単に作成できるからです (より単純なミューテックス/条件操作に基づいて、再帰的ミューテックスを自分で実装しました)。

私がよく理解していないこと: 非再帰的ミューテックスは何に適していますか? 同じミューテックスを 2 回ロックすると、スレッドのデッドロックが必要になるのはなぜですか? それを回避できる高水準言語でさえ (たとえば、これがデッドロックするかどうかをテストし、デッドロックする場合は例外をスローする)、通常はそれを行いません。代わりに、スレッドをデッドロックさせます。

これは、誤って 2 回ロックして 1 回だけロックを解除した場合のみであり、再帰的ミューテックスの場合、問題を見つけるのが難しいため、代わりにすぐにデッドロックして、間違ったロックが表示される場所を確認しますか? しかし、ロックを解除するときにロック カウンターを返すことで同じことを行うことはできませんでした。最後のロックを解放し、カウンターがゼロではないことが確実な状況では、例外をスローしたり、問題をログに記録したりできませんか? または、私が見落としている非再帰的ミューテックスの他のより便利なユースケースはありますか? それとも、非再帰的ミューテックスは再帰的ミューテックスよりもわずかに高速になる可能性があるため、単なるパフォーマンスでしょうか? ただし、これをテストしたところ、違いはそれほど大きくありません。

pthreadは、再帰的ミューテックスがロックされた回数を照会できるメソッドをサポートしていますか？

SOでこの回答を読みました：

再帰的ミューテックスには所有権があるため、ミューテックスを取得するスレッドは、ミューテックスを解放するスレッドと同じでなければなりません。非再帰的ミューテックスの場合、所有権の感覚はなく、どのスレッドが最初にミューテックスを取得したかに関係なく、通常はどのスレッドもミューテックスを解放できます。

最後の発言に戸惑います。あるスレッドがミューテックスをロックし、別のスレッドがそのミューテックスをロック解除できますか? ミューテックスのロックを解除できるのは同じスレッドだけだと思いましたか? または、これを許可する特定のミューテックスはありますか? 誰かが明確にしてくれることを願っています。

再帰ミューテックスを使用すると、デッドロックに陥ることなくミューテックスを複数回ロックでき、同じ回数ロックを解除する必要があることを理解しています。しかし、再帰ミューテックスを使用する必要があるのは、具体的にどのような状況でしょうか? デザイン/コードレベルの状況を探しています。

次のようなブースト ミューテックスとロックを使用するカスタム クラスがあります (関連する部分のみ)。

同じスレッドからオブジェクトを複数回ロックしようとすると、例外 (lock_error) が発生します。

これは出力です：

なぜこうなった？いくつかの概念を間違って理解していますか?

以下のコードでエラーが発生しました。

このエラーの原因は何ですか？

フロリダ州立大学の pthread 標準の実装が、ひょっとして、再帰的ミューテックスを処理できるかどうか疑問に思っています。残念ながら、FSU の実装に関するドキュメントはかなり貧弱であり、ミューテックスを再帰的として宣言する可能性についても言及していません。

次のようにミューテックスを宣言しようとしています:

FSU pthreads ライブラリを使用してコンパイルすると、次のエラー リストが表示されます。

私のマシンで（非FSU）pthread実装で同じコードをコンパイルしようとすると、動作します。

些細なことを避けるために、デフォルトでは、POSIX ミューテックスは再帰的ではないことを事前にお伝えします。

FSU 実装で再帰的ミューテックスを利用する方法はないと結論付けるべきですか、それともこれらを実現する別の方法 (つまり、ミューテックスを再帰的として宣言する別の方法) があるのでしょうか?

を呼び出しunlock()た後boost::recursive_mutex::scoped_lock、ロックオブジェクトはデストラクタで何らかの形でミューテックスを参照しますか？

ロックは、ロック解除の呼び出し後もミューテックスへの参照を保持します（つまりmutex()、同じポインターを返します）。release()ロックがスコープ外になる前にミューテックスが破壊された場合にも、ロックで呼び出す必要がありますか？

pthread を使用して再帰的ミューテックスを宣言する方法について、少し混乱しています。私がやろうとしているのは、一度に 1 つのスレッドだけがコード (関数を含む) を実行できるようにすることですが、懐疑的な見方をした後、ミューテックスの使用は機能せず、代わりに再帰ミューテックスを使用する必要があることがわかりました。これが私のコードです：

だから私がやろうとしているのは、キューから順番に読み取り/削除することです。

問題は、再帰的ミューテックスを宣言する方法に関する例がそこにないということです。または、いくつかあるかもしれませんが、それらは私のためにコンパイルされません。

で使用condition_variable_anyする場合recursive_mutex、待機中に他のスレッドから一般的にrecursive_mutex取得できますか？BoostとC++11の両方の実装に興味があります。condition_variable_any::wait

これは私が主に懸念しているユースケースです：