ICondition Interface

Définition

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

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

Dérivé

Java.Util.Concurrent.Locks.AbstractQueuedLongSynchronizer.ConditionObject

Java.Util.Concurrent.Locks.AbstractQueuedSynchronizer.ConditionObject

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable IDisposable

Remarques

Conditiondétermine les Object méthodes de surveillance (Object#wait() waitObject#notify notifyet Object#notifyAll notifyAll) en objets distincts pour donner l’effet d’avoir plusieurs jeux d’attente par objet, en les combinant avec l’utilisation d’implémentations arbitrairesLock. Lorsqu’un Lock remplace l’utilisation de synchronized méthodes et d’instructions, il Condition remplace l’utilisation des méthodes de surveillance d’objet.

Les conditions (également appelées<>< files d’attente de conditions em/em> ou <variables> de condition em<>) fournissent un moyen pour un thread de suspendre l’exécution (à " wait") jusqu’à ce qu’un autre thread indique que certaines conditions d’état peuvent maintenant être vraies. Étant donné que l’accès à ces informations d’état partagées se produit dans différents threads, il doit être protégé. Par conséquent, un verrou d’un formulaire est associé à la condition. La propriété de clé qui attend une condition fournit est qu’elle <>libère atomiquement</em> le verrou associé et suspend le thread actuel, comme Object.wait.

Une Condition instance est intrinsèquement liée à un verrou. Pour obtenir une Condition instance pour une instance particulière Lock , utilisez sa Lock#newCondition newCondition() méthode.

Par exemple, supposons que nous disposions d’une mémoire tampon limitée qui prend en charge put et take des méthodes. Si une take tentative est effectuée sur une mémoire tampon vide, le thread bloque jusqu’à ce qu’un élément soit disponible ; s’il put est tenté sur une mémoire tampon complète, le thread bloque jusqu’à ce qu’un espace soit disponible. Nous aimerions conserver les threads d’attente put et take les threads dans des ensembles d’attente distincts afin de pouvoir utiliser l’optimisation de la notification d’un seul thread à la fois lorsque des éléments ou des espaces deviennent disponibles dans la mémoire tampon. Cette opération peut être obtenue à l’aide de deux Condition instances.

class BoundedBuffer<E> {
<b>final Lock lock = new ReentrantLock();</b>
              final Condition notFull  = <b>lock.newCondition(); </b>
              final Condition notEmpty = <b>lock.newCondition(); </b>

              final Object[] items = new Object[100];
              int putptr, takeptr, count;

              public void put(E x) throws InterruptedException {
<b>lock.lock();
                try {</b>
                  while (count == items.length)
<b>notFull.await();</b>
                  items[putptr] = x;
                  if (++putptr == items.length) putptr = 0;
                  ++count;
<b>notEmpty.signal();</b>
<b>} finally {
                  lock.unlock();
                }</b>
              }

              public E take() throws InterruptedException {
<b>lock.lock();
                try {</b>
                  while (count == 0)
<b>notEmpty.await();</b>
                  E x = (E) items[takeptr];
                  if (++takeptr == items.length) takeptr = 0;
                  --count;
<b>notFull.signal();</b>
                  return x;
<b>} finally {
                  lock.unlock();
                }</b>
              }
            }

(La java.util.concurrent.ArrayBlockingQueue classe fournit cette fonctionnalité, il n’y a donc aucune raison d’implémenter cet exemple de classe d’utilisation.)

Une Condition implémentation peut fournir un comportement et une sémantique différents de ceux Object des méthodes de surveillance, telles que l’ordre garanti pour les notifications, ou ne nécessitant pas de verrouillage lors de l’exécution de notifications. Si une implémentation fournit une sémantique spécialisée, l’implémentation doit documenter ces sémantiques.

Notez que les Condition instances sont simplement des objets normaux et peuvent elles-mêmes être utilisées comme cible dans une synchronized instruction, et peuvent avoir leur propre analyse Object#wait wait et Object#notify notify méthodes appelées. L’acquisition du verrou de surveillance d’une Condition instance, ou l’utilisation de ses méthodes de surveillance, n’a aucune relation spécifiée avec l’acquisition Lock associée à celle-ci Condition ou l’utilisation de ses méthodes #await d’attente et d'#signal de signalisation. Il est recommandé d’éviter toute confusion que vous n’utilisez Condition jamais d’instances de cette façon, sauf peut-être 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.

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

Quand vous attendez un Condition, un "<em>spurious wakeup</em>" est autorisé à se produire, en général, en tant que concession à la sémantique de la plateforme sous-jacente. Cela a peu d’impact pratique sur la plupart des programmes d’application, car il Condition doit toujours être attendu dans une boucle, testant le prédicat d’état attendu. Une implémentation est gratuite pour supprimer la possibilité de réveils imperdieux, mais il est recommandé que les programmeurs d’applications supposent toujours qu’ils peuvent se produire et donc toujours attendre dans une boucle.

Les trois formes d’attente de condition (interromptible, non interromptible et chronométré) peuvent différer dans leur facilité d’implémentation sur certaines plateformes et dans leurs caractéristiques de performances. En particulier, il peut être difficile de fournir ces fonctionnalités et de maintenir une sémantique spécifique, comme les garanties de classement. En outre, la possibilité d’interrompre la suspension réelle du thread peut ne pas toujours être réalisable pour implémenter sur toutes les plateformes.

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’attente, ni pour prendre en charge l’interruption de la suspension réelle du thread.

Une implémentation est nécessaire pour documenter clairement la sémantique et les garanties fournies par chacune des méthodes en attente, et lorsqu’une implémentation prend en charge l’interruption de la suspension des threads, elle doit respecter la sémantique d’interruption telle que définie dans cette interface.

É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 une autre action qui a peut-être déblocé le thread. Une implémentation doit documenter ce comportement.

Ajouté à la version 1.5.

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

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.