ILock Interface

Définition

[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

Dérivé

Java.Util.Concurrent.Locks.ReentrantLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantReadLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantWriteLock

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable IDisposable

Remarques

Lock les implémentations fournissent des opérations de verrouillage plus étendues que celles qui peuvent être obtenues à l’aide synchronized de méthodes et d’instructions. Ils permettent une structure plus flexible, peuvent avoir des propriétés assez différentes et peuvent prendre en charge plusieurs objets associés Condition .

Un verrou est un outil permettant de contrôler l’accès à une ressource partagée par plusieurs threads. Généralement, un verrou fournit un accès exclusif à une ressource partagée : un seul thread à la fois peut acquérir le verrou et tout l’accès à la ressource partagée nécessite que le verrou soit acquis en premier. Toutefois, certains verrous peuvent autoriser l’accès simultané à une ressource partagée, comme le verrou de lecture d’un ReadWriteLock.

L’utilisation de méthodes ou d’instructions permet d’accéder au verrou de moniteur implicite associé à chaque objet, mais force l’acquisition et la libération de synchronized verrous à se produire de manière structurée par bloc : lorsque plusieurs verrous sont acquis, ils doivent être libérés dans l’ordre opposé, et tous les verrous doivent être libérés dans la même étendue lexicale dans laquelle ils ont été acquis.

Bien que le mécanisme d’étendue pour synchronized les méthodes et les instructions facilite beaucoup le programme avec des verrous de surveillance et permet d’éviter de nombreuses erreurs de programmation courantes impliquant des verrous, il existe des occasions où vous devez travailler avec des verrous de manière plus flexible. Par exemple, certains algorithmes permettant de parcourir des structures de données simultanément consultées nécessitent l’utilisation de " hand-over-hand" ou " chaînage" : vous acquérez le verrou du nœud A, puis le nœud B, puis relâchez A et acquérez C, puis relâchez B et acquérez D, et ainsi de suite. Les implémentations de l’interface Lock permettent l’utilisation de ces techniques en autorisant l’acquisition et la libération d’un verrou dans différentes étendues, et en autorisant l’acquisition et la libération de plusieurs verrous dans n’importe quel ordre.

Avec cette flexibilité accrue vient une responsabilité supplémentaire. L’absence de verrouillage structuré par bloc supprime la libération automatique des verrous qui se produisent avec synchronized des méthodes et des instructions. Dans la plupart des cas, l’idiome suivant doit être utilisé :

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

Lorsque le verrouillage et le déverrouillage se produisent dans différentes étendues, vous devez veiller à ce que tout le code exécuté pendant que le verrou soit conservé est protégé par try-finally ou try-catch pour vous assurer que le verrou est libéré si nécessaire.

Lock Les implémentations fournissent des fonctionnalités supplémentaires sur l’utilisation de synchronized méthodes et d’instructions en fournissant une tentative non bloquante d’acquérir un verrou (#tryLock()), une tentative d’acquisition du verrou qui peut être interrompu (#lockInterruptiblyet une tentative d’acquisition du verrou qui peut expirer (#tryLock(long, TimeUnit)).

Une Lock classe peut également fournir un comportement et une sémantique qui est tout à fait différent de celle du verrou du moniteur implicite, comme l’ordre garanti, l’utilisation non réentrante ou la détection de blocage. Si une implémentation fournit une sémantique spécialisée, l’implémentation doit documenter ces sémantiques.

Notez que les Lock instances sont simplement des objets normaux et peuvent elles-mêmes être utilisées comme cible dans une synchronized instruction. L’acquisition du verrou de surveillance d’une Lock instance n’a aucune relation spécifiée avec l’appel d’une des #lock méthodes de cette instance. Il est recommandé d’éviter toute confusion que vous n’utilisez Lock jamais d’instances de cette façon, sauf dans leur propre implémentation.

Sauf indication contraire, la transmission d’une null valeur pour n’importe quel paramètre entraîne une NullPointerException levée.

<Synchronisation> de la mémoire h2</h2>

Toutes les implémentations em doivent/emLock appliquer la même sémantique de synchronisation de mémoire que celle fournie par le verrou de moniteur intégré, comme décrit dans le chapitre 17 de <la citation>The Java Language Specification</cite> : <ul><li A>réussite < de l’opération a les mêmes effets de synchronisation de mémoire qu’une action em>Lock</em> réussielock.<><> <Li>Une opération réussie unlock a les mêmes effets de synchronisation de mémoire qu’une action em<Unlock>/em< réussie>. </ul>

Les opérations de verrouillage et de déverrouillage infructueuses, ainsi que les opérations de verrouillage/déverrouillage, ne nécessitent aucun effet de synchronisation de mémoire.

<Considérations relatives> à l’implémentation h2</h2>

Les trois formes d’acquisition de verrous (interromptibles, non interromptibles et chronométrés) peuvent différer dans leurs caractéristiques de performances, les garanties de classement ou d’autres qualités d’implémentation. En outre, la possibilité d’interrompre l’acquisition <>en cours</em> d’un verrou peut ne pas être disponible dans une classe donnéeLock. Par conséquent, une implémentation n’est pas nécessaire pour définir exactement les mêmes garanties ou sémantiques pour les trois formes d’acquisition de verrous, ni pour prendre en charge l’interruption d’une acquisition de verrous en cours. Une implémentation est nécessaire pour documenter clairement la sémantique et les garanties fournies par chacune des méthodes de verrouillage. Elle doit également respecter la sémantique d’interruption telle que définie dans cette interface, dans la mesure où l’interruption de l’acquisition de verrous est prise en charge : ce qui est totalement ou uniquement sur l’entrée de méthode.

Étant donné que l’interruption implique généralement l’annulation et que les vérifications d’interruption sont souvent peu fréquentes, une implémentation peut favoriser la réponse à une interruption par rapport à un retour de méthode normal. Cela est vrai même s’il peut être démontré que l’interruption s’est produite après qu’une autre action a pu débloquer le thread. Une implémentation doit documenter ce comportement.

Ajouté à la version 1.5.

Java documentation pour java.util.concurrent.locks.Lock.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.