同期コードの匂い？

Question

私は多くのマルチスレッドコードを解析しています。私は非常に多くのロックを見ています。いくつかのメソッドは、次のような行に2つのロックを持ちます：

ClassA::foo() 
{ 
    lockA.lock(); 
    lockB.lock(); 

    ...//do some stuff 

    lockB.unlock(); 
    lockA.unlock(); 
} 

私の質問は非常に一般的です（実際のコードは提供できません）。これはコードのにおいですか？これは一般的に悪い習慣ですか？コードを単純化できることは証明できませんが、コードが正しくコーディングされていれば、2つのものをロックする必要はないでしょう。ロックは、同期が必要な一連のリソースを管理する必要があります。リソースの管理と重複する2つのロックがある場合、いくつかのデッドロックの問題がありますか？

洞察があれば教えてください。

おかげで、 JBU

Answer 1

それはそれ自体でコードのにおいを表すものではありませんので、コードの一部は、2つのロックを取る必要がすることは非常に一般的です。これらのロックがの場合は常にとなりますが、それは問題になります。しかし、別々にロックを取る場所が他にある場合は、このパターンは問題ありません。

コードスニペットで唯一コメントしたいのは、RAIIロッククラスを使用してコードを例外セーフにし、他の種類のコードエラーを回避することです（誤っていくつかのコードパスでロック）。

Answer 2

コンテキストやプロジェクトの範囲によっては、匂いかもしれませんが、そうでないかもしれません。キューに登録されているリストを同期させるために5つのロックを操作すると、何か間違ったことが起こっている可能性があります。一般的に私は共有資源とロックの間に良い1-1の比を持っていたい。

細かいレベルでロックすることが魅力的な場合もあります（リスト全体をロックするのではなく、リストの各アイテムをロックする）。プロファイラーがあなたにロックが大量に提供されていると言うまで、その要望を再現してください。

他の場合、単一のリソースを保護するのではなく、多くの競合が発生しないことを知っている特定のbussiness-logicを保護するために、ロックを使用して複数のロックを1つにまとめることができます。あなたは少しパフォーマンスが落ちるかもしれませんが、10個のロックを取り除くことができれば、それはテーブルにもたらすシンプルさのために通常は価値があります。

あなたの質問に対する答えは質問の形であると思います。なぜあなたのクラスAは2つの共有リソースを同時に使用していますか？一般的には、何らかの種類の単一責任主義の原則を使用して設計段階で回避しようとするものです。通常、共有リソースは誰かに属し、誰かがリソースのロック/ロック解除に関する単一の権限です。確認するために

lockA.lock(); 
//some code 
lockA.unlock(); 
lockB.lock(); 
//some other code 
lockB.unlock(); 

一つの明確なもの：

あなたがメソッドをリファクタリングすることができます任意の方法はあります（つまりLOCKA> lockB）のロックを注文する所定の有限/定義された方法のみロックがあるはずですそれらを昇順に並べ替えます。

別のスレッドのメソッドは、ClassBの::バー（）{lockB.lock（）のような何かをした場合あなたは

lockA.lock(); 
lockB.lock(); 

や他のいくつかのコードで

lockB.lock(); 
lockA.lock();