それはすべて、ユースケースによって異なります。ロック/ロック解除/ロック/ロック解除のパフォーマンス ペナルティはどれくらい許容できますか? これを考慮して、ロックを待っている間に別のタスクをどれくらいブロックしても構わないと思っていますか? 一部のスレッドはレイテンシが重要または対話的であり、他のスレッドはバルクまたは優先度が低いですか? 他のコード パスを介して同じロックを取得する他のタスクはありますか? もしそうなら、それらはどのように見えますか? callA
、などのクリティカル セクションcallB
が本当に分かれている場合、26 個の異なるロックを使用しますか? それとも、同じデータを操作して、単一のロックを使用するように強制しますか?
ところで、Linux を使用している場合は、セマフォではなく (pthreads) ミューテックスを必ず使用してください。ミューテックスの高速パスは完全にユーザー空間です。競合がないときにそれらをロックおよびロック解除することは、非常に安価です。セマフォには高速パスはありません。
他に何も知らなくても、特に個々の関数がすでに組織化されており、ロックがすべての関数で保持されている場合にのみ当てはまる仮定を作成しない場合は、きめ細かいロックをお勧めします。しかし、私が言ったように、それはあなたが何をしているのか、なぜそれをしているのかに大きく依存します.