Semaphore Classe

Définition

[Android.Runtime.Register("java/util/concurrent/Semaphore", DoNotGenerateAcw=true)]
public class Semaphore : Java.Lang.Object, IDisposable, Java.IO.ISerializable

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

Héritage

Object

JavaObject

Object

Semaphore

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable ISerializable IDisposable

Remarques

Sémaphore de comptage. Conceptuellement, un sémaphore conserve un ensemble de permis. Chaque #acquire bloc si nécessaire jusqu’à ce qu’un permis soit disponible, puis l’accepte. Chacun #release ajoute un permis, potentiellement la libération d’un acquéreur bloquant. Toutefois, aucun objet d’autorisation réel n’est utilisé ; le Semaphore juste maintient un nombre du nombre disponible et agit en conséquence.

Les sémaphores sont souvent utilisés pour limiter le nombre de threads que pour accéder à une ressource (physique ou logique). Par exemple, voici une classe qui utilise un sémaphore pour contrôler l’accès à un pool d’éléments :

{@code
            class Pool {
              private static final int MAX_AVAILABLE = 100;
              private final Semaphore available = new Semaphore(MAX_AVAILABLE, true);

              public Object getItem() throws InterruptedException {
                available.acquire();
                return getNextAvailableItem();
              }

              public void putItem(Object x) {
                if (markAsUnused(x))
                  available.release();
              }

              // Not a particularly efficient data structure; just for demo

              protected Object[] items = ...; // whatever kinds of items being managed
              protected boolean[] used = new boolean[MAX_AVAILABLE];

              protected synchronized Object getNextAvailableItem() {
                for (int i = 0; i < MAX_AVAILABLE; ++i) {
                  if (!used[i]) {
                    used[i] = true;
                    return items[i];
                  }
                }
                return null; // not reached
              }

              protected synchronized boolean markAsUnused(Object item) {
                for (int i = 0; i < MAX_AVAILABLE; ++i) {
                  if (item == items[i]) {
                    if (used[i]) {
                      used[i] = false;
                      return true;
                    } else
                      return false;
                  }
                }
                return false;
              }
            }}

Avant d’obtenir un élément, chaque thread doit obtenir un permis auprès du sémaphore, garantissant qu’un élément est disponible pour une utilisation. Une fois le thread terminé avec l’élément qu’il est retourné au pool et qu’un permis est retourné au sémaphore, ce qui permet à un autre thread d’acquérir cet élément. Notez qu’aucun verrou de synchronisation n’est conservé lorsqu’il #acquire est appelé, car cela empêcherait un élément d’être retourné au pool. Le sémaphore encapsule la synchronisation nécessaire pour restreindre l’accès au pool, séparément de toute synchronisation nécessaire pour maintenir la cohérence du pool lui-même.

Un sémaphore initialisé à un, qui est utilisé de telle sorte qu’il n’a qu’un seul permis disponible, peut servir de verrou d’exclusion mutuelle. Il s’agit plus couramment d’un <sémaphore>/em< binaire em>, car il n’a que deux états : un permis disponible ou zéro permis disponible. Lorsqu’il est utilisé de cette façon, le sémaphore binaire a la propriété (contrairement à de nombreuses java.util.concurrent.locks.Lock implémentations), que le " lock" peut être libéré par un thread autre que le propriétaire (car les sémaphores n’ont aucune notion de propriété). Cela peut être utile dans certains contextes spécialisés, tels que la récupération de blocage.

Le constructeur de cette classe accepte éventuellement un <paramètre em>fairness</em> . Lorsque la valeur est définie false, cette classe ne garantit pas l’ordre dans lequel les threads obtiennent des autorisations. En particulier, <le>barging</em> est autorisé, c’est-à-dire qu’un thread appelant #acquire peut être alloué un permis avant un thread qui attendait - logiquement le nouveau thread se place à la tête de la file d’attente des threads en attente. Lorsque l’équité est définie sur true, le sémaphore garantit que les threads appelant l’une des #acquire() acquire méthodes sont sélectionnées pour obtenir des permis dans l’ordre dans lequel leur appel de ces méthodes a été traité (premier in-first-out ; FIFO). Notez que l’ordre FIFO s’applique nécessairement à des points internes spécifiques d’exécution au sein de ces méthodes. Par conséquent, il est possible qu’un thread s’appelle acquire avant un autre, mais atteigne le point de classement après l’autre, et de la même façon lors du retour de la méthode. Notez également que les méthodes intempestives #tryAcquire() tryAcquire ne respectent pas le paramètre d’équité, mais acceptent les permis disponibles.

En règle générale, les sémaphores utilisés pour contrôler l’accès aux ressources doivent être initialisés comme justes pour s’assurer qu’aucun thread n’est privé d’accès à une ressource. Lorsque vous utilisez des sémaphores pour d’autres types de contrôle de synchronisation, les avantages du débit de l’ordre non équitable l’emportent souvent sur les considérations d’équité.

Cette classe fournit également des méthodes pratiques pour #acquire(int) acquire et #release(int) release plusieurs permis à la fois. Ces méthodes sont généralement plus efficaces et plus efficaces que les boucles. Toutefois, ils n’établissent aucun ordre de préférence. Par exemple, si le thread A appelle ) et que le thread B appelle s.acquire(3s.acquire(2), et que deux permis deviennent disponibles, il n’existe aucune garantie que le thread B les obtiendra, sauf si son acquisition est arrivée en premier et que le sémaphore s est en mode équitable.

Effets de cohérence de la mémoire : actions dans un thread avant d’appeler une méthode « release » telle que release()<i>happen-before</i> actions suivant une méthode « acquire » réussie, comme acquire() dans un autre thread.

Ajouté à la version 1.5.

Java documentation pour java.util.concurrent.Semaphore.

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.