低レベルのロックを減らすために適用できる戦略が必要であり、疑問に思っています。ただし、これはサーバー アプリケーション用の新しいコード (数万行の C++ コード) ではないため、すべてを書き直すことはできません。
この問題の解決策は今のところないのではないかと心配しています (遅すぎます)。ただし、他の人が使用した良いパターンについて聞きたいです。
現在、ロックが多すぎて競合が少ないため、パラノイアによって引き起こされたハードウェア パフォーマンスの問題です。コードを説明する最良の方法は、シングル スレッド コードが突然ロックでいっぱいになることです。
低レベルのロックを排除する必要があるのはなぜですか? デッドロックの問題がありますか? パフォーマンスに問題がありますか? それともスケーリングの問題？ロックは一般的に競合していますか、それとも競合していませんか?
どのような環境を使用していますか? たとえば、C++ での回答は Java での回答とは異なります。たとえば、Java 6 の非競合同期ブロックは、実際にはパフォーマンス面で比較的安価であるため、JRE をアップグレードするだけで、解決しようとしている問題を回避できる可能性があります。別のコンパイラまたはロック ライブラリに切り替えることで、C++ でも同様のパフォーマンス向上が得られる場合があります。
一般に、取得するミューテックスの数を減らす方法はいくつかあります。
まず、1 つのスレッドからのみアクセスされるものにはミューテックスは必要ありません。
第 2 に、「安全に公開」されている (つまり、部分的に構築されたオブジェクトが別のスレッドから見えないように作成されている) 場合、不変のものはすべて安全です。
3 番目に、ほとんどのプラットフォームがアトミック書き込みをサポートするようになりました。これは、単一のプリミティブ型 (ポインターを含む) だけを保護する必要がある場合に役立ちます。これらは、データベースの楽観的ロックと非常によく似た働きをします。アトミック書き込みを使用してロックフリー アルゴリズムを作成し、Map 実装などのより複雑な型を置き換えることもできます。ただし、非常に優れている場合を除き、他の人のデバッグ済みの実装を借りる方がはるかに優れています (java.util.concurrent パッケージには多くの優れた例が含まれています)。独自のアルゴリズムを作成するときに、誤ってバグを導入することはよく知られています。
第 4 に、mutex の範囲を広げると、ミューテックスを絶えずロックしたりロック解除したりするのではなく、単純に長く開いたままにするか、「より大きな」項目 (たとえば、そのプロパティの 1 つではなくオブジェクト) をロックすることができます。 . ただし、これは非常に慎重に行う必要があります。この方法で問題を簡単に導入できます。
プログラムのスレッド モデルは、1 行を書き込む前に決定する必要があります。モジュールがプログラムの残りの部分と一致しない場合、アプリケーションがクラッシュしたり、アプリケーションが破損したり、デッドロックが発生したりする可能性があります。
新たに始める余裕がある場合は、並列に実行できるプログラムの大きな関数を特定し、スレッド プールを使用してタスクをスケジュールするようにしてください。効率化の秘訣は、可能な限りミューテックスを回避し、アプリを (再) コーディングして、高レベルでのリソースの競合を回避することです。