ReentrantReadWriteLock Classe

Définition

[Android.Runtime.Register("java/util/concurrent/locks/ReentrantReadWriteLock", DoNotGenerateAcw=true)]
public class ReentrantReadWriteLock : Java.Lang.Object, IDisposable, Java.IO.ISerializable, Java.Util.Concurrent.Locks.IReadWriteLock

[<Android.Runtime.Register("java/util/concurrent/locks/ReentrantReadWriteLock", DoNotGenerateAcw=true)>]
type ReentrantReadWriteLock = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface IReadWriteLock

Héritage

Object

JavaObject

Object

ReentrantReadWriteLock

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable ISerializable IReadWriteLock IDisposable

Remarques

Implémentation de la prise en charge de ReadWriteLock la sémantique similaire à ReentrantLock.

Cette classe a les propriétés suivantes :

<ul><li><b>Acquisition order</b>

Cette classe n’impose pas d’ordre de préférence de lecteur ou d’enregistreur pour l’accès verrouillé. Toutefois, elle prend en charge une stratégie facultative <d’équité></em>.

<dl><dt><b>Mode non équitable (valeur par défaut)</b><dd>Lorsqu’il est construit comme non équitable (valeur par défaut), l’ordre d’entrée du verrou de lecture et d’écriture n’est pas spécifié, soumis à des contraintes de réentrance. Un verrou non équitable qui est continuellement soutenu peut reporter indéfiniment un ou plusieurs threads de lecteur ou d’enregistreur, mais aura normalement un débit plus élevé qu’un verrou équitable.

<dt><b>Mode fair</b><dd>Lorsqu’il est construit comme équitable, les threads prétendent entrer à l’aide d’une stratégie d’ordre d’arrivée approximative. Lorsque le verrou actuellement conservé est libéré, soit le thread d’écriture unique en attente le plus long soit affecté au verrou d’écriture, soit s’il existe un groupe de threads de lecteur en attente plus long que tous les threads d’enregistreur en attente, ce groupe reçoit le verrou de lecture.

Un thread qui tente d’acquérir un verrou de lecture équitable (sans reentrantly) bloque si le verrou d’écriture est conservé ou s’il existe un thread d’enregistreur en attente. Le thread n’acquiert pas le verrou de lecture tant que le thread d’écriture en attente le plus ancien n’a pas acquis et libéré le verrou d’écriture. Bien sûr, si un enregistreur en attente abandonne son attente, laissant un ou plusieurs threads de lecteur en tant que serveurs les plus longs dans la file d’attente avec le verrou d’écriture libre, ces lecteurs reçoivent le verrou de lecture.

Un thread qui tente d’acquérir un verrou d’écriture équitable (sans reentrantly) se bloque, sauf si le verrou de lecture et le verrou d’écriture sont libres (ce qui implique qu’il n’y a pas de threads en attente). (Notez que les méthodes et ReadLock#tryLock() non bloquantes WriteLock#tryLock() ne respectent pas ce paramètre équitable et acquiert immédiatement le verrou s’il est possible, indépendamment des threads en attente.) </dl>

<li><b>Reentrancy</b>

Ce verrou permet aux lecteurs et aux écrivains de réacquire les verrous de lecture ou d’écriture dans le style d’un ReentrantLock. Les lecteurs non réentrants ne sont pas autorisés tant que tous les verrous d’écriture détenus par le thread d’écriture n’ont pas été libérés.

En outre, un enregistreur peut acquérir le verrou de lecture, mais pas inversement. Parmi les autres applications, la réentrance peut être utile lorsque des verrous d’écriture sont conservés pendant les appels ou rappels aux méthodes qui effectuent des lectures sous des verrous de lecture. Si un lecteur tente d’acquérir le verrou d’écriture, il ne réussira jamais.

<li><b>Verrouillage rétrogradation</b>

La réentrance autorise également la rétrogradation du verrou d’écriture vers un verrou de lecture, en acquérant le verrou d’écriture, puis en libérant le verrou d’écriture. Toutefois, la mise à niveau d’un verrou de lecture vers le verrou d’écriture n’est <pas> b</b> possible.

<li><b>Interruption de l’acquisition< de verrou/b>

Le verrou de lecture et le verrou d’écriture prennent tous les deux en charge l’interruption pendant l’acquisition du verrou.

<support li><b>Condition</b>

Le verrou d’écriture fournit une Condition implémentation qui se comporte de la même façon, en ce qui concerne le verrou d’écriture, comme l’implémentation Condition fournie pour ReentrantLock#newConditionReentrantLock. Cela Condition peut, bien sûr, être utilisé uniquement avec le verrou d’écriture.

Le verrou de lecture ne prend pas en charge une Condition et readLock().newCondition() lève UnsupportedOperationException.

<li><b>Instrumentation</b>

Cette classe prend en charge les méthodes pour déterminer si les verrous sont conservés ou soutenus. Ces méthodes sont conçues pour surveiller l’état du système, et non pour le contrôle de synchronisation. </ul>

La sérialisation de cette classe se comporte de la même façon que les verrous intégrés : un verrou désérialisé est dans l’état déverrouillé, quel que soit son état lors de la sérialisation.

<b>Exemples d’utilisations.</b> Voici un croquis de code montrant comment effectuer une rétrogradation des verrous après la mise à jour d’un cache (la gestion des exceptions est particulièrement délicate lors de la gestion de plusieurs verrous de manière non imbriquée) :

{@code
            class CachedData {
              Object data;
              boolean cacheValid;
              final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

              void processCachedData() {
                rwl.readLock().lock();
                if (!cacheValid) {
                  // Must release read lock before acquiring write lock
                  rwl.readLock().unlock();
                  rwl.writeLock().lock();
                  try {
                    // Recheck state because another thread might have
                    // acquired write lock and changed state before we did.
                    if (!cacheValid) {
                      data = ...;
                      cacheValid = true;
                    }
                    // Downgrade by acquiring read lock before releasing write lock
                    rwl.readLock().lock();
                  } finally {
                    rwl.writeLock().unlock(); // Unlock write, still hold read
                  }
                }

                try {
                  use(data);
                } finally {
                  rwl.readLock().unlock();
                }
              }
            }}

ReentrantReadWriteLocks peut être utilisé pour améliorer la concurrence dans certaines utilisations de certains types de collections. Cela vaut généralement la peine d’être utile uniquement lorsque les collections sont censées être volumineuses, accessibles par plus de threads de lecture que de threads d’écriture, et impliquent des opérations avec une surcharge qui dépasse la surcharge de synchronisation. Par exemple, voici une classe utilisant un TreeMap qui est censé être volumineux et accessible simultanément.

{@code
            class RWDictionary {
              private final Map<String, Data> m = new TreeMap<>();
              private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
              private final Lock r = rwl.readLock();
              private final Lock w = rwl.writeLock();

              public Data get(String key) {
                r.lock();
                try { return m.get(key); }
                finally { r.unlock(); }
              }
              public List<String> allKeys() {
                r.lock();
                try { return new ArrayList<>(m.keySet()); }
                finally { r.unlock(); }
              }
              public Data put(String key, Data value) {
                w.lock();
                try { return m.put(key, value); }
                finally { w.unlock(); }
              }
              public void clear() {
                w.lock();
                try { m.clear(); }
                finally { w.unlock(); }
              }
            }}

<Notes> d’implémentation h2</h2>

Ce verrou prend en charge un maximum de 65535 verrous d’écriture récursifs et 65535 verrous de lecture. Les tentatives de dépassement de ces limites entraînent Error des levées de méthodes de verrouillage.

Ajouté à la version 1.5.

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

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.