IReadWriteLock Interface

Définition

[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

Dérivé

Java.Util.Concurrent.Locks.ReentrantReadWriteLock

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable IDisposable

Remarques

A ReadWriteLock gère une paire d’opérations associées Lock locks, une pour les opérations en lecture seule et une pour l’écriture. Le #readLock verrou de lecture peut être conservé simultanément par plusieurs threads de lecture, tant qu’il n’y a pas d’enregistreurs. Le verrou d’écriture #writeLock est exclusif.

Toutes les ReadWriteLock implémentations doivent garantir que les effets de synchronisation de la mémoire des writeLock opérations (comme spécifié dans l’interface Lock ) sont également en attente par rapport au paramètre associé readLock. Autrement dit, un thread qui acquiert le verrou de lecture voit toutes les mises à jour effectuées lors de la version précédente du verrou d’écriture.

Un verrou en lecture-écriture permet un niveau d’accès concurrentiel supérieur à celui autorisé par un verrou d’exclusion mutuelle. Il exploite le fait que, même si un seul thread à la fois (un <thread em>writer</em>) peut modifier les données partagées, dans de nombreux cas, n’importe quel nombre de threads peuvent lire simultanément les données (par conséquent<>, em reader</em> threads). En théorie, l’augmentation de la concurrence autorisée par l’utilisation d’un verrou en lecture-écriture entraînera des améliorations des performances par rapport à l’utilisation d’un verrou d’exclusion mutuelle. Dans la pratique, cette augmentation de la concurrence sera entièrement réalisée sur un multiprocesseur, puis uniquement si les modèles d’accès pour les données partagées sont appropriés.

Si un verrou en lecture-écriture améliore les performances par rapport à l’utilisation d’un verrou d’exclusion mutuelle dépend de la fréquence à laquelle les données sont lues par rapport à la modification, à la durée des opérations de lecture et d’écriture, et à la contention des données , autrement dit, le nombre de threads qui essaieront de lire ou d’écrire les données en même temps. Par exemple, une collection qui est initialement remplie avec des données et par la suite rarement modifiée, tout en étant fréquemment recherchée (par exemple, un répertoire d’un type quelconque) est un candidat idéal pour l’utilisation d’un verrou en lecture-écriture. Toutefois, si les mises à jour deviennent fréquentes, les données passent la plupart du temps exclusivement verrouillées et il y a peu, si une augmentation de la concurrence est faible. En outre, si les opérations de lecture sont trop courtes, la surcharge de l’implémentation du verrou en lecture-écriture (qui est intrinsèquement plus complexe qu’un verrou d’exclusion mutuelle) peut dominer le coût d’exécution, en particulier lorsque de nombreuses implémentations de verrous en lecture-écriture sérialisent toujours tous les threads via une petite section de code. En fin de compte, seul le profilage et la mesure déterminent si l’utilisation d’un verrou en lecture-écriture convient à votre application.

Bien que l’opération de base d’un verrou en lecture-écriture soit simple, il existe de nombreuses décisions de stratégie qu’une implémentation doit prendre, ce qui peut affecter l’efficacité du verrou en lecture-écriture dans une application donnée. Voici quelques exemples de ces stratégies : <ul><li déterminer>s’il faut accorder le verrou de lecture ou le verrou d’écriture, lorsque les lecteurs et les enregistreurs attendent, au moment où un enregistreur libère le verrou d’écriture. La préférence de l’enregistreur est courante, car les écritures sont censées être courtes et peu fréquentes. La préférence du lecteur est moins courante, car elle peut entraîner des retards longs pour une écriture si les lecteurs sont fréquents et de longue durée comme prévu. Fair, ou " in-order" les implémentations sont également possibles.

<li>Déterminer si les lecteurs qui demandent le verrou de lecture pendant qu’un lecteur est actif et qu’un enregistreur attend, reçoivent le verrou de lecture. La préférence pour le lecteur peut retarder indéfiniment l’enregistreur, tandis que la préférence pour l’enregistreur peut réduire le risque d’accès concurrentiel.

<li>Déterminer si les verrous sont reentrants : un thread avec le verrou d’écriture peut-il être réacquiré ? Peut-il acquérir un verrou de lecture tout en maintenant le verrou d’écriture ? Le verrou de lecture lui-même est-il réentrant ?

<li>Le verrou d’écriture peut-il être rétrogradé en verrou de lecture sans autoriser un enregistreur intermédiaire ? Un verrou de lecture peut-il être mis à niveau vers un verrou d’écriture, en préférence pour d’autres lecteurs ou enregistreurs en attente ?

</ul> Vous devez prendre en compte toutes ces choses lors de l’évaluation de la pertinence d’une implémentation donnée pour votre application.

Ajouté à la version 1.5.

Documentation Java pour java.util.concurrent.locks.ReadWriteLock.

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

Propriétés

Méthodes

Méthodes d’extension

S’applique à