IReadWriteLock Schnittstelle

Referenz

Definition

Namespace:: Java.Util.Concurrent.Locks

Assembly:: Mono.Android.dll

Wichtig

Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.

A ReadWriteLock verwaltet ein zugehörigen Lock locksPaar , eines für schreibgeschützte Vorgänge und eins zum Schreiben.

[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

Abgeleitet: Java.Util.Concurrent.Locks.ReentrantReadWriteLock

Attribute: RegisterAttribute

Implementiert: IJavaObject IJavaPeerable IDisposable

Hinweise

A ReadWriteLock verwaltet ein zugehörigen Lock locksPaar , eines für schreibgeschützte Vorgänge und eins zum Schreiben. Die #readLock Lesesperre kann gleichzeitig von mehreren Lesethreads gehalten werden, solange keine Autoren vorhanden sind. Die #writeLock Schreibsperre ist exklusiv.

Alle ReadWriteLock Implementierungen müssen sicherstellen, dass auch die Speichersynchronisierungseffekte von writeLock Vorgängen (wie in der Lock Schnittstelle angegeben) in Bezug auf die zugeordnete readLock. Das heißt, ein Thread, der die Lesesperre erfolgreich abruft, sieht alle Aktualisierungen, die bei vorheriger Veröffentlichung der Schreibsperre vorgenommen wurden.

Eine Lese-/Schreibsperre ermöglicht eine höhere Parallelität beim Zugriff auf freigegebene Daten als dies durch eine gegenseitige Ausschlusssperre zulässig ist. Es nutzt die Tatsache, dass während nur ein einzelner Thread gleichzeitig (em <writer/em> thread) die freigegebenen Daten ändern kann, in vielen Fällen kann eine beliebige Anzahl von Threads die Daten gleichzeitig lesen (daher <em>reader</em> Threads).<> Theoretisch führt die Erhöhung der Parallelität, die durch die Verwendung einer Lese-/Schreibsperre zulässig ist, zu Leistungsverbesserungen bei der Verwendung einer gegenseitigen Ausschlusssperre. In der Praxis wird diese Erhöhung der Parallelität nur auf einem Multiprozessor vollständig realisiert und dann nur dann, wenn die Zugriffsmuster für die freigegebenen Daten geeignet sind.

Unabhängig davon, ob eine Lese-/Schreibsperre die Leistung über die Verwendung einer gegenseitigen Ausschlusssperre verbessert, hängt von der Häufigkeit ab, mit der die Daten im Vergleich zur Änderung gelesen werden, der Dauer der Lese- und Schreibvorgänge sowie der Inhalt der Daten – d. h. die Anzahl der Threads, die versuchen, die Daten gleichzeitig zu lesen oder zu schreiben. Beispielsweise ist eine Sammlung, die zunächst mit Daten aufgefüllt und danach selten geändert wird, während häufig durchsucht wird (z. B. ein Verzeichnis irgendeiner Art), ein idealer Kandidat für die Verwendung einer Lese-/Schreibsperre. Wenn Updates jedoch häufig werden, verbringen die Daten die meiste Zeit ausschließlich gesperrt, und es gibt wenig, wenn eine Erhöhung der Parallelität. Wenn die Lesevorgänge zu kurz sind, kann der Aufwand für die Implementierung der Lese-/Schreibsperre (die inhärent komplexer als eine gegenseitige Ausschlusssperre ist) die Ausführungskosten beherrschen, insbesondere da viele Lese-/Schreibsperrimplementierungen weiterhin alle Threads über einen kleinen Codeabschnitt serialisieren. Letztendlich wird nur profilieren und messen, ob die Verwendung einer Lese-/Schreibsperre für Ihre Anwendung geeignet ist.

Obwohl der grundlegende Betrieb einer Lese-/Schreibsperre gerade ausgeführt wird, gibt es viele Richtlinienentscheidungen, die eine Implementierung treffen muss, was sich auf die Effektivität der Lese-/Schreibsperre in einer bestimmten Anwendung auswirken kann. Beispiele für diese Richtlinien sind: <ul><li>Bestimmen, ob die Lesesperre oder die Schreibsperre gewährt werden soll, wenn sowohl Leser als auch Autoren warten, wenn ein Autor die Schreibsperre loslässt. Die Schreibeinstellung ist üblich, da Schreibvorgänge kurz und selten sein werden. Die Leseeinstellung ist weniger häufig, da sie zu langen Verzögerungen für einen Schreibvorgang führen kann, wenn die Leser häufig und langlebig wie erwartet sind. Fair, oder " In-Reihenfolge" Implementierungen sind ebenfalls möglich.

<li>Bestimmen, ob Leser, die die Lesesperre anfordern, während ein Leser aktiv ist und ein Autor wartet, erhalten die Lesesperre. Die Einstellung für den Leser kann den Autor auf unbestimmte Zeit verzögern, während die Präferenz für den Autor das Potenzial für Parallelität verringern kann.

<li>Bestimmen, ob die Sperren erneut ausgeführt werden: Kann ein Thread mit der Schreibsperre sie erneut abrufen? Kann eine Lesesperre beim Halten der Schreibsperre erworben werden? Wird die Lesesperre selbst erneut aktiviert?

<li>Kann die Schreibsperre auf eine Lesesperre herabgestuft werden, ohne einen dazwischen liegenden Autor zuzulassen? Kann eine Lesesperre auf eine Schreibsperre aktualisiert werden, vor anderen wartenden Lesern oder Autoren?

</ul> Sie sollten all diese Dinge berücksichtigen, wenn Sie die Eignung einer bestimmten Implementierung für Ihre Anwendung bewerten.

Hinzugefügt in 1.5.

Java-Dokumentation für java.util.concurrent.locks.ReadWriteLock.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die vom Android Open Source-Projekt erstellt und freigegeben werden und gemäß den in der Creative Commons 2.5 Attribution License beschriebenen Begriffen verwendet werden.

Eigenschaften

Handle	Ruft den JNI-Wert des zugrunde liegenden Android-Objekts ab. (Geerbt von IJavaObject)
JniIdentityHashCode	Gibt den Wert `java.lang.System.identityHashCode()` für die umbrochene Instanz zurück. (Geerbt von IJavaPeerable)
JniManagedPeerState	Status des verwalteten Peers. (Geerbt von IJavaPeerable)
JniPeerMembers	Mitgliedszugriff und Aufrufunterstützung. (Geerbt von IJavaPeerable)
PeerReference	Gibt eine JniObjectReference der umbrochenen Java-Objektinstanz zurück. (Geerbt von IJavaPeerable)

Methoden

Disposed()	Wird aufgerufen, wenn die Instanz verworfen wurde. (Geerbt von IJavaPeerable)
DisposeUnlessReferenced()	Wenn keine offenen Verweise auf diese Instanz vorhanden sind, wird nichts aufgerufen `Dispose()`. Andernfalls wird nichts ausgeführt. (Geerbt von IJavaPeerable)
Finalized()	Wird aufgerufen, wenn die Instanz abgeschlossen wurde. (Geerbt von IJavaPeerable)
ReadLock()	Gibt die zum Lesen verwendete Sperre zurück.
SetJniIdentityHashCode(Int32)	Legen Sie den von `JniIdentityHashCode`. (Geerbt von IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)	A `ReadWriteLock` verwaltet ein zugehörigen `Lock locks`Paar , eines für schreibgeschützte Vorgänge und eins zum Schreiben. (Geerbt von IJavaPeerable)
SetPeerReference(JniObjectReference)	Legen Sie den von `PeerReference`. (Geerbt von IJavaPeerable)
UnregisterFromRuntime()	Heben Sie die Registrierung dieser Instanz auf, damit die Laufzeit sie nicht aus zukünftigen Java.Interop.JniRuntime+JniValueManager.PeekValue Aufrufen zurückgibt. (Geerbt von IJavaPeerable)
WriteLock()	Gibt die zum Schreiben verwendete Sperre zurück.

Erweiterungsmethoden

JavaCast<TResult>(IJavaObject)	Führt eine android-laufzeitgecheckte Typkonvertierung aus.
JavaCast<TResult>(IJavaObject)	A `ReadWriteLock` verwaltet ein zugehörigen `Lock locks`Paar , eines für schreibgeschützte Vorgänge und eins zum Schreiben.
GetJniTypeName(IJavaPeerable)	A `ReadWriteLock` verwaltet ein zugehörigen `Lock locks`Paar , eines für schreibgeschützte Vorgänge und eins zum Schreiben.

Gilt für:

Freigeben über