c - 多くのミューテックス ロックの使用

Question

複数のスレッドが同時に動作する大きなツリー構造があります。理想的には、セルごとに個別のミューテックス ロックが必要です。

pthread_mutex_tinの定義を調べたところ、bits/pthreadtypes.hかなり短いので、私の場合、メモリ使用量は問題になりません。

pthread_mutex_tしかし、わずか 8 つのスレッドに対して多数 (数千としましょう) の異なる を使用すると、パフォーマンスが低下することはありますか?

Answer 1

ロックとロック解除を頻繁に行う場合、ロックの取得と解放には時間がかかり、ロックが競合しているとかなりの時間がかかる可能性があるため、ペナルティが発生する可能性があります。

このような構造で多くのロックを使用する場合は、各ロックが実際に何をロックするかについて非常に具体的にする必要があり、AB-BAデッドロックに注意する必要があります。たとえば、ロック操作中にツリーの構造を変更する場合は、変更されるすべてのノードを一貫した順序でロックし、子孫で動作するスレッドが混乱しないようにする必要があります。

非常に多くのロックがメモリ全体に分散している場合、アーキテクチャによっては、キャッシュの問題によってパフォーマンスの問題が発生する可能性があります。ロック操作は通常、キャッシュの少なくとも一部を無効にするためです。

おそらく最善の策は、単純なロック構造を実装し、それをプロファイリングしてから、必要に応じてパフォーマンスを向上させるために改良することです。ツリーで何をしているのかわかりませんが、更新するよりもはるかに多くの情報を読み取ることを期待している場合は、ツリー全体の単一のリーダーライターロックから始めることをお勧めします。

「私たちは小さな効率を忘れるべきです。たとえば、97％の確率で、時期尚早の最適化がすべての悪の根源です。」 -ドナルド・クヌース

Answer 2

これを適切に評価するには、ロック/アクセスパターンを記述する必要があります。各スレッドが一度に1つまたは少数のロックしか保持せず、2つ以上のスレッドが同時に同じロックを必要とする可能性が低い場合（ランダムアクセスパターンまたは円形トラックの異なる位置にある8つのランナー）ほぼ同じ速度または他のより複雑なもので実行している場合）、ロックを取得するためにスレッドをスリープ状態にする必要がある（または、場合によっては、誰が勝つかを決定するためにOSを関与させる必要がある）という最悪のケースを回避できます。スレッドが少なく、ロックが非常に多い。

各スレッドが一度に数百または数千のロックを必要とする場合、状況は変化し始めます。

使用しているコンテナーについては何も知らないため、デッドロックの回避については触れませんが、デッドロックを回避する必要があることに注意する必要があります。