System.Threading.Monitor.Wait-Methoden

Dieser Artikel enthält ergänzende Hinweise zur Referenzdokumentation für diese API.

Wait(Object, Int32, Boolean)-Methode

Diese Methode kehrt erst zurück, wenn sie ein exklusives Lock für den Parameter obj zurückerlangt hat.

Der Thread, der derzeit die Sperre für das angegebene Objekt besitzt, ruft diese Methode auf, um das Objekt freizugeben, damit ein anderer Thread darauf zugreifen kann. Der Aufrufer wird blockiert, während er darauf wartet, die Sperre wiederzuerlangen. Diese Methode wird aufgerufen, wenn der Aufrufer auf eine Zustandsänderung warten muss, die aufgrund der Vorgänge eines anderen Threads auftritt.

Durch das Timeout wird sichergestellt, dass der aktuelle Thread nicht auf unbestimmte Zeit blockiert wird, wenn ein anderer Thread die Sperre loslässt, ohne zuerst die Pulse- oder PulseAll-Methode aufzurufen. Außerdem verschiebt sie den Thread in die Readiness-Warteschlange und umgeht damit andere Threads, die in der Warteschlange vor ihm stehen, sodass er das Lock früher wiedererlangen kann. Der Thread kann den Rückgabewert der Methode Wait testen, um festzustellen, ob er das Lock vor dem Timeout wiedererlangt hat. Der Thread kann die Bedingungen auswerten, die dazu geführt haben, dass er in die Warteschlange eingetreten ist, und gegebenenfalls die Methode Wait erneut aufrufen.

Wenn ein Thread Wait aufruft, gibt er die Sperre frei und wechselt zum Warteschlangenmodus. Zu diesem Zeitpunkt hat der nächste Thread in der Warteschlange (sofern vorhanden) die Möglichkeit, die Kontrolle über das Lock zu übernehmen. Der Thread, der Wait aufgerufen hat, bleibt in der Warteschlange, bis entweder ein Thread, der die Sperre hält, PulseAll aufruft, oder bis er als Nächster in der Warteschlange steht und ein Thread, der die Sperre hält, Pulse aufruft. Wenn jedoch millisecondsTimeout verstreicht, bevor ein anderer Thread die Pulse- oder PulseAll-Methode dieses Objekts aufruft, wird der ursprüngliche Thread in die Readiness-Warteschlange verschoben, um das Lock wiederzuerlangen.

Hinweis

Wenn Infinite für den millisecondsTimeout-Parameter angegeben wird, blockiert diese Methode unbegrenzt, es sei denn, der Inhaber der Sperre ruft Pulse oder PulseAll auf. Wenn millisecondsTimeout gleich 0 ist, gibt der Thread, der Wait aufruft, das Lock frei und geht dann sofort in die Readiness Warteschlange, um das Lock wiederzuerlangen.

Der Anrufer führt Wait einmal aus, unabhängig davon, wie oft Enter für das angegebene Objekt aufgerufen wurde. Konzeptionell speichert die Wait-Methode, wie oft der Aufrufer Enter auf das Objekt angewendet hat, und ruft Exit so oft auf, wie nötig ist, um das gesperrte Objekt vollständig freizugeben. Der Aufrufer blockiert dann, während darauf gewartet wird, das Objekt erneut abzurufen. Wenn der Anrufer das Lock wiedererlangt, ruft das System Enter so oft wie nötig auf, um die gespeicherte Enter Anzahl für den Anrufer wiederherzustellen. Durch Aufrufen Wait wird die Sperre nur für das angegebene Objekt freigegeben. Wenn der Aufrufer der Besitzer von Sperren für andere Objekte ist, werden diese Sperren nicht freigegeben.

Hinweis

Ein synchronisiertes Objekt enthält mehrere Verweise, einschließlich eines Verweises auf den Thread, der derzeit die Sperre enthält, einen Verweis auf die bereite Warteschlange, die die Threads enthält, die zum Abrufen der Sperre bereit sind, und einen Verweis auf die Warteschleife, die die Threads enthält, die auf eine Benachrichtigung über eine Änderung im Zustand des Objekts warten.

Die Pulse Methoden, PulseAll Methoden und Wait Methoden müssen innerhalb eines synchronisierten Codeblocks aufgerufen werden.

In den Hinweisen für die Pulse-Methode wird erläutert, was passiert, wenn Pulse aufgerufen wird, während keine Threads warten.

Wait(Object, TimeSpan, Boolean)-Methode

Diese Methode kehrt erst zurück, wenn sie ein exklusives Lock für den Parameter obj zurückerlangt hat.

Der Thread, der derzeit die Sperre für das angegebene Objekt besitzt, ruft diese Methode auf, um das Objekt freizugeben, damit ein anderer Thread darauf zugreifen kann. Der Aufrufer wird blockiert, während er darauf wartet, die Sperre wiederzuerlangen. Diese Methode wird aufgerufen, wenn der Aufrufer auf eine Zustandsänderung warten muss, die aufgrund der Vorgänge eines anderen Threads auftritt.

Durch das Timeout wird sichergestellt, dass der aktuelle Thread nicht auf unbestimmte Zeit blockiert wird, wenn ein anderer Thread die Sperre loslässt, ohne zuerst die Pulse- oder PulseAll-Methode aufzurufen. Außerdem verschiebt sie den Thread in die Readiness-Warteschlange und umgeht damit andere Threads, die in der Warteschlange vor ihm stehen, sodass er das Lock früher wiedererlangen kann. Der Thread kann den Rückgabewert der Methode Wait testen, um festzustellen, ob er das Lock vor dem Timeout wiedererlangt hat. Der Thread kann die Bedingungen auswerten, die dazu geführt haben, dass er in die Warteschlange eingetreten ist, und gegebenenfalls die Methode Wait erneut aufrufen.

Wenn ein Thread Wait aufruft, gibt er die Sperre frei und wechselt zum Warteschlangenmodus. Zu diesem Zeitpunkt hat der nächste Thread in der Warteschlange (sofern vorhanden) die Möglichkeit, die Kontrolle über das Lock zu übernehmen. Der Thread, der Wait aufgerufen hat, bleibt in der Warteschlange, bis entweder ein Thread, der die Sperre hält, PulseAll aufruft, oder bis er als Nächster in der Warteschlange steht und ein Thread, der die Sperre hält, Pulse aufruft. Wenn jedoch timeout Millisekunden vergehen, bevor ein anderer Thread die Pulse- oder PulseAll-Methode dieses Objekts aufruft, wird der ursprüngliche Thread in die Bereit-Warteschlange gestellt, um die Sperre erneut zu erlangen.

Hinweis

Wenn für den Parameter TimeSpan ein timeout angegeben wird, der für -1 Millisekunde steht, blockiert diese Methode auf unbestimmte Zeit, es sei denn, der Inhaber des Locks ruft Pulse oder PulseAll auf. Wenn timeout 0 Millisekunden beträgt, gibt der Thread, der Wait aufruft, die Sperre frei und tritt dann sofort in die Warteschlange ein, um die Sperre wieder zu erlangen.

Der Anrufer führt Wait einmal aus, unabhängig davon, wie oft Enter für das angegebene Objekt aufgerufen wurde. Konzeptionell speichert die Wait-Methode, wie oft der Aufrufer Enter auf das Objekt angewendet hat, und ruft Exit so oft auf, wie nötig ist, um das gesperrte Objekt vollständig freizugeben. Der Aufrufer blockiert dann, während darauf gewartet wird, das Objekt erneut abzurufen. Wenn der Anrufer das Lock wiedererlangt, ruft das System Enter so oft wie nötig auf, um die gespeicherte Enter Anzahl für den Anrufer wiederherzustellen. Durch Aufrufen Wait wird die Sperre nur für das angegebene Objekt freigegeben. Wenn der Aufrufer der Besitzer von Sperren für andere Objekte ist, werden diese Sperren nicht freigegeben.

Hinweis

Ein synchronisiertes Objekt enthält mehrere Verweise, einschließlich eines Verweises auf den Thread, der derzeit die Sperre enthält, einen Verweis auf die bereite Warteschlange, die die Threads enthält, die zum Abrufen der Sperre bereit sind, und einen Verweis auf die Warteschleife, die die Threads enthält, die auf eine Benachrichtigung über eine Änderung im Zustand des Objekts warten.

Die Pulse Methoden, PulseAll Methoden und Wait Methoden müssen innerhalb eines synchronisierten Codeblocks aufgerufen werden.

In den Hinweisen für die Pulse-Methode wird erläutert, was passiert, wenn Pulse aufgerufen wird, während keine Threads warten.

Kontext verlassen

DerexitContext Parameter hat keine Auswirkung, es sei denn, die Wait Methode wird aus einem nicht standardmäßigen verwalteten Kontext aufgerufen. Dies kann passieren, wenn sich Ihr Thread innerhalb eines Aufrufs einer Instanz einer von ContextBoundObject abgeleiteten Klasse befindet. Auch wenn Sie derzeit eine Methode an einer Klasse ausführen, die nicht von ContextBoundObject abgeleitet ist, wie String, können Sie sich in einem nicht standardmäßigen Kontext befinden, wenn sich ein ContextBoundObject in Ihrem Stapel im aktuellen Anwendungsbereich befindet.

Wenn der Code in einem nicht standardmäßigen Kontext ausgeführt wird, führt die Angabe von true für exitContext dazu, dass der Thread den nicht standardmäßigen verwalteten Kontext verlässt (d. h. in den Standardkontext wechselt), bevor er die Wait-Methode ausführt. Er kehrt in den ursprünglichen Nicht-Standard-Kontext zurück, nachdem der Aufruf der Wait Methode abgeschlossen ist.

Dies kann nützlich sein, wenn die kontextgebundene Klasse das SynchronizationAttribute Attribut angewendet hat. In diesem Fall werden alle Aufrufe an Member der Klasse automatisch synchronisiert, und die Synchronisierungsdomäne ist der gesamte Codetext für die Klasse. Wenn Code im Aufrufstapel eines Mitglieds die Wait Methode aufruft und true für exitContext angibt, beendet der Thread die Synchronisierungsdomäne, sodass ein Thread, der bei einem Aufruf eines Mitglieds des Objekts blockiert wird, fortgesetzt werden kann. Wenn die Wait Methode zurückkehrt, muss der Thread, der den Aufruf ausgeführt hat, warten, bis er die Synchronisierungsdomäne erneut betreten kann.