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