IReadWriteLock Interfaccia
Definizione
Importante
Alcune informazioni sono relative alla release non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.
Una ReadWriteLock gestisce una coppia di operazioni associate Lock locks, una per 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
- Attributi
- Implementazioni
Commenti
Una ReadWriteLock gestisce una coppia di operazioni associate Lock locks, una per operazioni di sola lettura e una per la scrittura. Il #readLock blocco di lettura 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) contengano anche rispetto all'oggetto Lock associato readLock. Vale a dire, un thread che acquisisce correttamente il blocco di lettura visualizzerà tutti gli aggiornamenti apportati 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 quello consentito 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 <em>reader</em> thread). In teoria, l'aumento della concorrenza consentito dall'uso di un blocco di lettura-scrittura porterà a miglioramenti delle prestazioni sull'uso di un blocco di esclusione reciproca. In pratica, questo aumento della concorrenza sarà completamente realizzato in un multiprocessore e quindi solo se i modelli di accesso per i dati condivisi sono adatti.
Se un blocco di lettura-scrittura migliora le prestazioni sull'uso di un blocco di esclusione reciproca dipende dalla frequenza di lettura o scrittura dei dati rispetto alla modifica, alla durata delle operazioni di lettura e scrittura e alla contesa per i dati, ovvero il numero di thread che tenteranno di leggere o scrivere i dati contemporaneamente. Ad esempio, una raccolta inizialmente popolata con dati e successivamente modificata raramente, mentre viene eseguita una ricerca frequente (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 passano la maggior parte del tempo in modo esclusivo bloccato e c'è poco, se qualsiasi aumento della concorrenza. Inoltre, se le operazioni di lettura sono troppo brevi il sovraccarico dell'implementazione del blocco di lettura-scrittura (che è intrinsecamente più complessa di un blocco di esclusione reciproca) può dominare il costo di esecuzione, in particolare molte implementazioni di blocchi di lettura-scrittura ancora 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 è direttamente avanti, esistono molte decisioni dei criteri che un'implementazione deve prendere, che possono 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 sia lettori che 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 raramente. La preferenza per il lettore è meno comune perché può causare ritardi lunghi per una scrittura se i lettori sono frequenti e di lunga durata come previsto. Fair, o " in ordine&virgolette; sono anche possibili implementazioni.
<li>Determinare se i 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 in modo indefinito, mentre la preferenza per il writer può ridurre il potenziale di concorrenza.
<li>Determinare se i blocchi sono reentrant: un thread con il blocco di scrittura lo riacquisire? Può acquisire un blocco di lettura tenendo premuto 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 di intervento? È possibile aggiornare un blocco di lettura a un blocco di scrittura, in preferenza ad altri lettori o writer in attesa?
</ul> È consigliabile considerare tutte queste operazioni 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 in base al lavoro creato e condiviso dal Android Open Source e usato in base ai termini descritti nella .
Proprietà
| Handle |
Ottiene il valore JNI dell'oggetto Android sottostante. (Ereditato da IJavaObject) |
| JniIdentityHashCode |
Restituisce il valore di per |
| JniManagedPeerState |
Stato del peer gestito. (Ereditato da IJavaPeerable) |
| JniPeerMembers |
Supporto per l'accesso ai membri e la chiamata. (Ereditato da IJavaPeerable) |
| PeerReference |
Restituisce un'istanza JniObjectReference dell'oggetto Java con 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 |
| Finalized() |
Chiamato quando l'istanza è stata finalizzata. (Ereditato da IJavaPeerable) |
| ReadLock() |
Restituisce il blocco usato per la lettura. |
| SetJniIdentityHashCode(Int32) |
Impostare il valore restituito da |
| SetJniManagedPeerState(JniManagedPeerStates) |
Una |
| SetPeerReference(JniObjectReference) |
Impostare il valore restituito da |
| UnregisterFromRuntime() |
Annullare la registrazione di questa istanza in modo che il runtime non lo restituirà dalle chiamate future Java.Interop.JniRuntime+JniValueManager.PeekValue . (Ereditato da IJavaPeerable) |
| WriteLock() |
Restituisce il blocco usato per la scrittura. |
Metodi di estensione
| JavaCast<TResult>(IJavaObject) |
Esegue una conversione dei tipi controllati dal runtime Android. |
| JavaCast<TResult>(IJavaObject) |
Una |
| GetJniTypeName(IJavaPeerable) |
Una |