IReadWriteLock インターフェイス
定義
重要
一部の情報は、リリース前に大きく変更される可能性があるプレリリースされた製品に関するものです。 Microsoft は、ここに記載されている情報について、明示または黙示を問わず、一切保証しません。
は ReadWriteLock 、関連付けられた Lock locksのペアを保持します。1 つは読み取り専用操作用、もう 1 つは書き込み用です。
[Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")]
public interface IReadWriteLock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable[<Android.Runtime.Register("java/util/concurrent/locks/ReadWriteLock", "", "Java.Util.Concurrent.Locks.IReadWriteLockInvoker")>]
type IReadWriteLock = interface
interface IJavaObject
interface IDisposable
interface IJavaPeerable- 派生
- 属性
- 実装
注釈
は ReadWriteLock 、関連付けられた Lock locksのペアを保持します。1 つは読み取り専用操作用、もう 1 つは書き込み用です。 #readLock 読み取りロックは、ライターがない限り、複数のリーダー スレッドによって同時に保持される場合があります。 #writeLock 書き込みロックは排他的です。
すべてのReadWriteLock実装では、(インターフェイスでLock指定されている) 操作のwriteLockメモリ同期効果も、関連付けられている readLockに関して保持されることを保証する必要があります。 つまり、スレッドが読み取りロックを正常に取得すると、書き込みロックの以前のリリース時に行われたすべての更新が表示されます。
読み取り/書き込みロックを使用すると、共有データへのアクセスにおいて、相互排他ロックによって許可されるよりも高いレベルのコンカレンシーが可能になります。 これは、一度に 1 つのスレッド ( <em>ライター</em> スレッド) のみが共有データを変更できる一方で、多くの場合、任意の数のスレッドが同時にデータを読み取ることができるという事実を悪用します (したがって <、em>reader</em> スレッド)。 理論的には、読み取り/書き込みロックの使用によって許可されるコンカレンシーの増加は、相互除外ロックの使用に対するパフォーマンスの向上につながります。 実際には、このコンカレンシーの増加はマルチプロセッサでのみ完全に実現され、共有データのアクセス パターンが適切な場合にのみ実現されます。
読み取り/書き込みロックによって、相互除外ロックの使用に対するパフォーマンスが向上するかどうかは、変更と比較してデータが読み取られる頻度、読み取り操作と書き込み操作の期間、およびデータの競合 (つまり、同時にデータの読み取りまたは書き込みを試みるスレッドの数) によって異なります。 たとえば、最初にデータが設定され、その後ほとんど変更されないコレクションが頻繁に検索される (何らかの種類のディレクトリなど) ことが、読み取り/書き込みロックの使用に最適です。 ただし、更新が頻繁に行われると、データはほとんどの時間を排他的にロックされ、コンカレンシーが増加する場合はほとんど発生しません。 さらに、読み取り操作が短すぎる場合は、読み取り/書き込みロック実装のオーバーヘッド (本質的に相互排他ロックよりも複雑です) が実行コストを上回る可能性があります。特に、読み取り/書き込みロック実装の数が小さなセクションのコードを通じてすべてのスレッドをシリアル化する場合は特に多くなります。 最終的には、プロファイリングと測定のみが、読み取り/書き込みロックの使用がアプリケーションに適しているかどうかを確立します。
読み取り/書き込みロックの基本的な操作は簡単ですが、実装で行う必要があるポリシーの決定は多数あります。これは、特定のアプリケーションでの読み取り/書き込みロックの有効性に影響する可能性があります。 これらのポリシーの例としては、 <読み取りロックを許可するか書き込みロックを許可するかを決定する ul><li>(リーダーとライターの両方が待機しているときに、ライターが書き込みロックを解放する時点) などがあります。 書き込みは短く、頻度が低い場合が予想されるため、ライターの優先設定は一般的です。 リーダーの設定は、読み取りが予想どおりに頻繁で有効期間が長い場合、書き込みの遅延が長くなる可能性があるため、あまり一般的ではありません。 公正、または &量子。順序&量子。実装も可能です。
<li>リーダーがアクティブでライターが待機している間に読み取りロックを要求するリーダーに読み取りロックが付与されているかどうかを判断します。 リーダーに優先すると、ライターが無期限に遅延する可能性があります。一方、ライターを優先すると、コンカレンシーの可能性が低下する可能性があります。
<li>ロックが再入可能かどうかを判断する: 書き込みロックを持つスレッドはそれを再取得できますか? 書き込みロックを保持しているときに読み取りロックを取得できますか? 読み取りロック自体は再入可能ですか?
<li>書き込みロックを読み取りロックにダウングレードすることはできますか。 読み取りロックは、他の待機中のリーダーまたはライターに優先して、書き込みロックにアップグレードできますか?
</ul> アプリケーションの特定の実装の適合性を評価するときは、これらすべてのことを考慮する必要があります。
1\.5 で追加されました。
の Java ドキュメント java.util.concurrent.locks.ReadWriteLock。
このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。
プロパティ
| Handle |
基になる Android オブジェクトの JNI 値を取得します。 (継承元 IJavaObject) |
| JniIdentityHashCode |
ラップされたインスタンスの の |
| JniManagedPeerState |
マネージド ピアの状態。 (継承元 IJavaPeerable) |
| JniPeerMembers |
メンバー アクセスと呼び出しのサポート。 (継承元 IJavaPeerable) |
| PeerReference |
JniObjectReferenceラップされた Java オブジェクト インスタンスの を返します。 (継承元 IJavaPeerable) |
メソッド
| Disposed() |
インスタンスが破棄されたときに呼び出されます。 (継承元 IJavaPeerable) |
| DisposeUnlessReferenced() |
このインスタンスへの未処理の参照がない場合は、 を呼び出 |
| Finalized() |
インスタンスが終了したときに呼び出されます。 (継承元 IJavaPeerable) |
| ReadLock() |
読み取りに使用されるロックを返します。 |
| SetJniIdentityHashCode(Int32) |
によって返される値を |
| SetJniManagedPeerState(JniManagedPeerStates) |
は |
| SetPeerReference(JniObjectReference) |
によって返される値を |
| UnregisterFromRuntime() |
ランタイムが将来 Java.Interop.JniRuntime+JniValueManager.PeekValue の呼び出しから返されないように、このインスタンスの登録を解除します。 (継承元 IJavaPeerable) |
| WriteLock() |
書き込みに使用されるロックを返します。 |
拡張メソッド
| JavaCast<TResult>(IJavaObject) |
Android ランタイムチェック型変換を実行します。 |
| JavaCast<TResult>(IJavaObject) |
は |
| GetJniTypeName(IJavaPeerable) |
は |