- 既知のすべての実装クラス:
ReentrantReadWriteLock
ReadWriteLockは、読取り専用操作用および書込み用の、関連するlocksのペアを制御します。 read lockは、ライターが存在しないかぎり、複数のリーダー・スレッドが同時に保持できます。 write lockは排他的です。
すべてのReadWriteLock実装で、関連付けられたreadLockに関してwriteLock操作のメモリー同期効果(Lockインタフェースで指定されている)も保持されていることを保証する必要があります。 つまり、正常に読込みロックを取得したスレッドでは、書込みロックが前回解放されたときに行われたすべての更新内容を認識します。
読み込み - 書込みロックを使用すると、相互排他ロックを使用する場合よりも広範な並行性を共有データへのアクセスに持たせることができます。 これは、共有データを変更できるのは1回につき1つのスレッド(ライター・スレッド)だけであるにもかかわらず、多くの場合は任意の数のスレッド(リーダー・スレッド)がデータを並行して読み取ることができるという事実を利用します。 理論上は、読み込み - 書込みロックの使用で許可される並行性を向上させると、相互排他ロックを使用する場合と比べてパフォーマンスが向上します。 実際には、並行性向上が十分に実現されるのは、複数のプロセッサ上で使用され、共有データのアクセス・パターンが適している場合だけです。
読み込み - 書込みロックにより相互排他ロックよりもパフォーマンスが向上するかどうかは、データ変更に対するデータ読込みの頻度、読み込みおよび書込みの持続期間、およびデータの競合、つまり同時にデータを読み取るまたは書き込むスレッドの数に依存します。 たとえば、データが入れられたあと、あまり変更されることなく(ディレクトリなどが)頻繁に検索されるコレクションは、読み込み - 書込みロックの理想的な候補になります。ただし、更新が頻繁に行われる場合、データの時間の大半は排他的ロックに費やされるため、並行性は向上するとしてもごくわずかです。 さらに、読込み操作の時間が短すぎると、読み込み - 書込みロックの実装によるオーバーヘッド(本来、相互排他ロックよりも複雑)により実行コストが支配されてしまう可能性があります。 多数の読み込み - 書込みロック実装が少ないコード・セクションですべてのスレッドを直列化する場合は、特にこのことが当てはまります。結局のところ、読み込み - 書込みロックが使用するアプリケーションに適しているかどうかを調べるには、プロ・ファイリングと計測を実行するしかありません。 読み込み - 書込みロックの基本操作は複雑ではありませんが、実装で行う必要のあるポリシー上の決定が多数存在します。
これらの決定は、指定されたアプリケーションでの読み込み - 書込みロックの効果性に影響を与える場合があります。 これらのポリシーの例を、次に示します。
- ライターが書込みロックを解放したときに、読込みロックまたは書込みロックを許可するかどうか、いつリーダーおよびライターの両方を待機させるかを決定する。 ライターは短期的で使用頻度も少ないことが期待されるため、ライター優先は一般的である。 リーダーが予想どおり頻繁に実行されて長時間の場合、書込みの遅延が大きくなるため、リーダー優先は一般的ではない。 公平、つまり「順序」実装も可能である。
- リーダーがアクティブでライターが待機中に、読込みロックを要求したリーダーが読込みロックを許可されるかどうかを判別する。 ライターに対する優先が並行性の可能性を低下させる可能性があるのに対し、リーダーに対する優先はライターを無制限に遅らせる可能性がある。
- 次を判定します - ロックが再入可能か: 書込みロックを持つスレッドがそれを再取得可能か。 書込みロックを持ちながら読込みロックを取得可能か。 読込みロック自体が再入可能か。
- 介入するライターを許可することなく、書込みロックを読込みロックに降格可能か。 読込みロックを、待機中のほかのリーダーやライターよりも優先して書込みロックに昇格可能か。
- 導入されたバージョン:
- 1.5
- 関連項目:
-
メソッドのサマリー