Semaphore Klasse

Definition

[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

Vererbung

Object

JavaObject

Object

Semaphore

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable ISerializable IDisposable

Hinweise

Ein Zähl-Semaphor. Konzeptionell behält ein Semaphor eine Reihe von Genehmigungen bei. Jede #acquire Blöcke, sofern erforderlich, bis eine Genehmigung verfügbar ist, und nimmt sie dann. Jeder #release fügt eine Genehmigung hinzu, die potenziell einen blockierenden Acquirer freigibt. Es werden jedoch keine tatsächlichen Genehmigungsobjekte verwendet; die Semaphore Anzahl der verfügbaren Nummern wird nur beibehalten und entsprechend handlungen.

Semaphore werden häufig verwendet, um die Anzahl der Threads einzuschränken, als auf einige (physische oder logische) Ressourcen zugreifen können. Hier ist beispielsweise eine Klasse, die einen Semaphor verwendet, um den Zugriff auf einen Pool von Elementen zu steuern:

{@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;
              }
            }}

Vor dem Abrufen eines Elements muss jeder Thread eine Genehmigung vom Semaphor erwerben, wodurch sichergestellt wird, dass ein Element zur Verwendung verfügbar ist. Wenn der Thread mit dem Element fertig ist, wird es wieder an den Pool zurückgegeben, und eine Genehmigung wird an das Semaphor zurückgegeben, sodass ein anderer Thread dieses Element abrufen kann. Beachten Sie, dass keine Synchronisierungssperre gehalten wird, wenn #acquire sie aufgerufen wird, da dadurch verhindert wird, dass ein Element an den Pool zurückgegeben wird. Das Semaphor kapselt die Synchronisierung, die erforderlich ist, um den Zugriff auf den Pool einzuschränken, getrennt von jeder Synchronisierung, die erforderlich ist, um die Konsistenz des Pools selbst aufrechtzuerhalten.

Ein Semaphor initialisiert für eins, das so verwendet wird, dass es nur über höchstens eine genehmigungsfähig ist, kann als gegenseitige Ausschlusssperre dienen. Dies wird häufiger als em <>binary semaphor</em> bezeichnet, da sie nur zwei Zustände aufweist: eine Genehmigung verfügbar oder null genehmigungen verfügbar. Bei verwendung auf diese Weise hat der binäre Semaphor die Eigenschaft (im Gegensatz zu vielen java.util.concurrent.locks.Lock Implementierungen), dass das " sperren" kann von einem anderen Thread als dem Besitzer freigegeben werden (da Semaphoren keinen Besitz haben). Dies kann in einigen speziellen Kontexten hilfreich sein, z. B. die Deadlock-Wiederherstellung.

Der Konstruktor für diese Klasse akzeptiert optional einen <em>fairness</em-Parameter> . Wenn "false" festgelegt wird, garantiert diese Klasse keine Garantien für die Reihenfolge, in der Threads Genehmigungen erwerben. Insbesondere <ist em>barging</em> zulässig, d. h. ein Thread,der aufruft #acquire , kann eine Genehmigung vor einem Thread zugewiesen werden, der gewartet wurde - logisch platziert sich der neue Thread an der Spitze der Warteschleife von Wartethreads. Wenn die Fairness wahr ist, garantiert der Semaphor, dass Threads, die eine der #acquire() acquire Methoden aufrufen, ausgewählt werden, um Genehmigungen in der Reihenfolge zu erhalten, in der ihre Aufrufe dieser Methoden verarbeitet wurden (first-in-first-out; FIFO). Beachten Sie, dass die FIFO-Sortierung unbedingt auf bestimmte interne Ausführungspunkte innerhalb dieser Methoden angewendet wird. Daher ist es möglich, dass ein Thread vor einem anderen aufgerufen wird acquire , aber den Sortierpunkt nach dem anderen erreicht, und ähnlich, wenn die Methode zurückgegeben wird. Beachten Sie außerdem, dass die unbezeitigten #tryAcquire() tryAcquire Methoden die Fairnesseinstellung nicht berücksichtigen, sondern alle verfügbaren Genehmigungen übernehmen.

Im Allgemeinen sollten Semaphore, die zum Steuern des Ressourcenzugriffs verwendet werden, als fair initialisiert werden, um sicherzustellen, dass kein Thread vom Zugriff auf eine Ressource ausgehungert wird. Bei der Verwendung von Semaphoren für andere Arten der Synchronisierungskontrolle überwiegen die Durchsatzvorteile der nicht fairen Sortierung häufig die Fairnessüberlegungen.

Diese Klasse bietet auch Komfortmethoden und #acquire(int) acquire#release(int) release mehrere Genehmigungen gleichzeitig. Diese Methoden sind im Allgemeinen effizienter und effektiver als Schleifen. Sie richten jedoch keine Einstellungsreihenfolge ein. Wenn thread A beispielsweise aufruft s.acquire(3) und Thread B aufgerufen wird und zwei Genehmigungen s.acquire(2)verfügbar sind, gibt es keine Garantie dafür, dass Thread B sie erhält, es sei denn, der Erwerb erfolgte zuerst und Semaphor s ist im fairen Modus.

Auswirkungen der Speicherkonsistenz: Aktionen in einem Thread vor dem Aufrufen einer "Release"-Methode wie release()<i>happen-before</i-Aktionen> nach einer erfolgreichen "acquire"-Methode wie acquire() in einem anderen Thread.

Hinzugefügt in 1.5.

Java Dokumentation für java.util.concurrent.Semaphore.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.