IReadWriteLock Interfaccia

Definizione

Spazio dei nomi:

Java.Util.Concurrent.Locks

Assembly:

Mono.Android.dll

Un ReadWriteLock oggetto gestisce una coppia di , Lock locksuna per le operazioni di sola lettura e una per la scrittura.

[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

Derivato

Java.Util.Concurrent.Locks.ReentrantReadWriteLock

Attributi

RegisterAttribute

Implementazioni

IJavaObject IJavaPeerable IDisposable

Commenti

Un ReadWriteLock oggetto gestisce una coppia di , Lock locksuna per le operazioni di sola lettura e una per la scrittura. Il blocco di lettura #readLock può essere mantenuto simultaneamente da più thread di lettura, purché non ci siano writer. Il blocco di scrittura #writeLock è esclusivo.

Tutte le ReadWriteLock implementazioni devono garantire che gli effetti di sincronizzazione della memoria delle writeLock operazioni (come specificato nell'interfaccia Lock ) contengano anche rispetto all'oggetto associato readLock. Ovvero, un thread che acquisisce correttamente il blocco di lettura visualizzerà tutti gli aggiornamenti eseguiti al rilascio precedente del blocco di scrittura.

Un blocco di lettura/scrittura consente un livello di concorrenza maggiore nell'accesso ai dati condivisi rispetto a quelli consentiti da un blocco di esclusione reciproca. Sfrutta il fatto che, mentre solo un singolo thread alla volta (un <thread em>writer</em>) può modificare i dati condivisi, in molti casi qualsiasi numero di thread può leggere simultaneamente i dati (quindi <>thread em reader</em>). In teoria, l'aumento della concorrenza consentito dall'uso di un blocco di lettura/scrittura porterà a miglioramenti delle prestazioni rispetto all'uso di un blocco di esclusione reciproca. In pratica, questo aumento della concorrenza verrà realizzato completamente solo su un multiprocessore e quindi solo se i modelli di accesso per i dati condivisi sono adatti.

Il fatto che un blocco di lettura/scrittura migliorerà le prestazioni rispetto all'uso di un blocco di esclusione reciproca dipende dalla frequenza con cui i dati vengono letti rispetto a essere modificati, dalla durata delle operazioni di lettura e scrittura e dalla contesa per i dati, ovvero dal numero di thread che tenteranno di leggere o scrivere i dati contemporaneamente. Ad esempio, una raccolta che viene inizialmente popolata con dati e successivamente modificata raramente, mentre viene eseguita frequentemente la ricerca (ad esempio una directory di qualche tipo) è un candidato ideale per l'uso di un blocco di lettura/scrittura. Tuttavia, se gli aggiornamenti diventano frequenti, i dati trascorrono la maggior parte del tempo esclusivamente bloccato e c'è poco, se si verifica un aumento della concorrenza. Inoltre, se le operazioni di lettura sono troppo brevi, il sovraccarico dell'implementazione del blocco di lettura/scrittura (che è intrinsecamente più complesso di un blocco di esclusione reciproca) può dominare il costo di esecuzione, in particolare molte implementazioni di blocchi di lettura/scrittura continuano a serializzare tutti i thread tramite una piccola sezione di codice. In definitiva, solo la profilatura e la misurazione stabiliranno se l'uso di un blocco di lettura/scrittura è adatto per l'applicazione.

Anche se l'operazione di base di un blocco di lettura/scrittura è semplice, esistono molte decisioni relative ai criteri che un'implementazione deve prendere, che può influire sull'efficacia del blocco di lettura/scrittura in una determinata applicazione. Esempi di questi criteri includono: <ul><li>Determinare se concedere il blocco di lettura o il blocco di scrittura, quando i lettori e i writer sono in attesa, al momento in cui un writer rilascia il blocco di scrittura. La preferenza del writer è comune, poiché le scritture devono essere brevi e poco frequenti. La preferenza del lettore è meno comune perché può causare ritardi lunghi per una scrittura se i lettori sono frequenti e di lunga durata come previsto. Fair, or " in ordine" sono anche possibili implementazioni.

<li>Determinare se ai lettori che richiedono il blocco di lettura mentre un lettore è attivo e un writer è in attesa, viene concesso il blocco di lettura. La preferenza per il lettore può ritardare il writer per un periodo illimitato, mentre la preferenza al writer può ridurre il potenziale di concorrenza.

<li>Determinare se i blocchi sono reentrant: un thread con il blocco di scrittura riacquisirlo? Può acquisire un blocco di lettura mantenendo il blocco di scrittura? Il blocco di lettura è reentrant?

<li>Può essere effettuato il downgrade del blocco di scrittura a un blocco di lettura senza consentire un writer intermedio? Un blocco di lettura può essere aggiornato a un blocco di scrittura, in preferenza ad altri lettori o writer in attesa?

</ul> È consigliabile prendere in considerazione tutti questi aspetti quando si valuta l'idoneità di una determinata implementazione per l'applicazione.

Aggiunto nella versione 1.5.

Documentazione java per java.util.concurrent.locks.ReadWriteLock.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dal progetto Open Source Android e usato in base ai termini descritti nella licenza Creative Commons 2.5 Attribuzione.

Proprietà

Handle	Ottiene il valore JNI dell'oggetto Android sottostante. (Ereditato da IJavaObject)
JniIdentityHashCode	Restituisce il valore di java.lang.System.identityHashCode() per l'istanza di cui è stato eseguito il wrapping. (Ereditato da IJavaPeerable)
JniManagedPeerState	Stato del peer gestito. (Ereditato da IJavaPeerable)
JniPeerMembers	Supporto per l'accesso ai membri e la chiamata. (Ereditato da IJavaPeerable)
PeerReference	Restituisce un JniObjectReference oggetto dell'istanza dell'oggetto Java di cui è stato eseguito il wrapping. (Ereditato da IJavaPeerable)

Metodi

Disposed()	Chiamato quando l'istanza è stata eliminata. (Ereditato da IJavaPeerable)
DisposeUnlessReferenced()	Se non sono presenti riferimenti in sospeso a questa istanza, chiama Dispose(); in caso contrario, non esegue alcuna operazione. (Ereditato da IJavaPeerable)
Finalized()	Chiamato quando l'istanza è stata finalizzata. (Ereditato da IJavaPeerable)
ReadLock()	Restituisce il blocco utilizzato per la lettura.
SetJniIdentityHashCode(Int32)	Impostare il valore restituito da JniIdentityHashCode. (Ereditato da IJavaPeerable)
SetJniManagedPeerState(JniManagedPeerStates)	Un ReadWriteLock oggetto gestisce una coppia di , Lock locksuna per le operazioni di sola lettura e una per la scrittura. (Ereditato da IJavaPeerable)
SetPeerReference(JniObjectReference)	Impostare il valore restituito da PeerReference. (Ereditato da IJavaPeerable)
UnregisterFromRuntime()	Annullare la registrazione di questa istanza in modo che il runtime non lo restituisca dalle chiamate future Java.Interop.JniRuntime+JniValueManager.PeekValue . (Ereditato da IJavaPeerable)
WriteLock()	Restituisce il blocco utilizzato per la scrittura.

Metodi di estensione

JavaCast<TResult>(IJavaObject)	Esegue una conversione del tipo di tipo controllato dal runtime Android.
JavaCast<TResult>(IJavaObject)	Un ReadWriteLock oggetto gestisce una coppia di , Lock locksuna per le operazioni di sola lettura e una per la scrittura.
GetJniTypeName(IJavaPeerable)	Un ReadWriteLock oggetto gestisce una coppia di , Lock locksuna per le operazioni di sola lettura e una per la scrittura.