ILock Interfaccia

Definizione

[Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")]
public interface ILock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")>]
type ILock = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Derivato

Java.Util.Concurrent.Locks.ReentrantLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantReadLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantWriteLock

Attributi

RegisterAttribute

Implementazioni

IJavaObject IJavaPeerable IDisposable

Commenti

Lock le implementazioni forniscono operazioni di blocco più estese di quelle che è possibile ottenere usando synchronized metodi e istruzioni. Consentono una strutturazione più flessibile, possono avere proprietà molto diverse e possono supportare più oggetti associati Condition .

Un blocco è uno strumento per controllare l'accesso a una risorsa condivisa da più thread. In genere, un blocco fornisce accesso esclusivo a una risorsa condivisa: un solo thread alla volta può acquisire il blocco e tutto l'accesso alla risorsa condivisa richiede che il blocco venga acquisito per primo. Tuttavia, alcuni blocchi possono consentire l'accesso simultaneo a una risorsa condivisa, ad esempio il blocco in lettura di un oggetto ReadWriteLock.

L'uso di synchronized metodi o istruzioni fornisce l'accesso al blocco di monitoraggio implicito associato a ogni oggetto, ma forza l'acquisizione e il rilascio dei blocchi in modo strutturato in modo strutturato: quando vengono acquisiti più blocchi, devono essere rilasciati nell'ordine opposto e tutti i blocchi devono essere rilasciati nello stesso ambito lessicale in cui sono stati acquisiti.

Anche se il meccanismo di definizione dell'ambito per synchronized metodi e istruzioni rende molto più semplice programmare con i blocchi di monitoraggio e consente di evitare molti errori di programmazione comuni che coinvolgono blocchi, in alcune occasioni è necessario lavorare con i blocchi in modo più flessibile. Ad esempio, alcuni algoritmi per attraversare strutture di dati con accesso simultaneo richiedono l'uso di " hand-over-hand" o " blocco catena": si acquisisce il blocco del nodo A, quindi il nodo B, quindi rilasciare A e acquisire C, rilasciare B e acquisire D e così via. Le implementazioni dell'interfaccia consentono l'uso Lock di tali tecniche consentendo l'acquisizione e il rilascio di un blocco in ambiti diversi e consentendo l'acquisizione e il rilascio di più blocchi in qualsiasi ordine.

Con questa maggiore flessibilità è responsabilità aggiuntiva. L'assenza di blocco strutturato rimuove il rilascio automatico dei blocchi che si verifica con synchronized metodi e istruzioni. Nella maggior parte dei casi, è consigliabile usare il linguaggio seguente:

{@code
            Lock l = ...;
            l.lock();
            try {
              // access the resource protected by this lock
            } finally {
              l.unlock();
            }}

Quando si verificano blocchi e sblocci in ambiti diversi, è necessario prestare attenzione a assicurarsi che tutto il codice eseguito mentre il blocco sia protetto da try-finally o try-catch per assicurarsi che il blocco venga rilasciato quando necessario.

Lock le implementazioni forniscono funzionalità aggiuntive sull'uso di synchronized metodi e istruzioni fornendo un tentativo non bloccante di acquisire un blocco (#tryLock()), un tentativo di acquisire il blocco che può essere interrotto (#lockInterruptiblye un tentativo di acquisire il blocco che può timeout (#tryLock(long, TimeUnit)).

Una Lock classe può anche fornire comportamento e semantica molto diverso da quello del blocco di monitoraggio implicito, ad esempio l'ordinamento garantito, l'utilizzo non reentrant o il rilevamento di deadlock. Se un'implementazione fornisce una semantica così specializzata, l'implementazione deve documentare tali semantiche.

Si noti che Lock le istanze sono solo oggetti normali e possono essere usate come destinazione in un'istruzione synchronized . L'acquisizione del blocco di monitoraggio di un'istanza Lock non ha alcuna relazione specificata con la chiamata di uno dei #lock metodi di tale istanza. È consigliabile evitare confusione che non si usino Lock mai istanze in questo modo, tranne che all'interno della propria implementazione.

Se non specificato, il passaggio di un null valore per qualsiasi parametro comporterà la creazione di un'eccezione NullPointerException .

<h2>Sincronizzazione< memoria/h2>

Tutte le Lock implementazioni <em>must</em> applicano la stessa semantica di sincronizzazione della memoria fornita dal blocco di monitoraggio predefinito, come descritto nel capitolo 17 di <cite>The Java Language Specification</cite>: <ul><li>A successful lock operation has the same memory synchronization effects as a successful <em>Lock</em> action. <li>Un'operazione riuscita unlock ha gli stessi effetti di sincronizzazione della memoria di un'azione di sblocco</em> riuscita<>. </ul>

Le operazioni di blocco e sblocco non riuscite e le operazioni di blocco/sblocco reentrant non richiedono alcun effetto di sincronizzazione della memoria.

<Considerazioni sull'implementazione> h2</h2>

Le tre forme di acquisizione del blocco (interrompibili, non interrompibili e timed) possono variare in base alle caratteristiche di prestazioni, alle garanzie di ordinamento o ad altre qualità di implementazione. Inoltre, la possibilità di interrompere l'acquisizione <>in corso</em> di un blocco potrebbe non essere disponibile in una determinata Lock classe. Di conseguenza, un'implementazione non è necessaria per definire esattamente le stesse garanzie o semantiche per tutte e tre le forme di acquisizione di blocchi, né è necessario supportare l'interruzione di un'acquisizione di blocco in corso. Un'implementazione è necessaria per documentare chiaramente la semantica e le garanzie fornite da ognuno dei metodi di blocco. Deve inoltre rispettare la semantica di interruzione definita in questa interfaccia, nella misura in cui è supportata l'interruzione dell'acquisizione del blocco: che è totalmente o solo sulla voce del metodo.

Poiché l'interruzione implica in genere l'annullamento e i controlli per l'interruzione sono spesso poco frequenti, un'implementazione può favorire la risposta a un interrupt rispetto alla restituzione normale del metodo. Questo vale anche se può essere mostrato che l'interrupt si è verificato dopo un'altra azione potrebbe aver sbloccato il thread. Un'implementazione deve documentare questo comportamento.

Aggiunto nella versione 1.5.

per java.util.concurrent.locks.Lock.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dalla e usati in base ai termini descritti in Creative License 2.5 Attribution License.