(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde maschinell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

WaitHandle.WaitOne-Methode (Int32, Boolean)

Blockiert den aktuellen Thread, bis das aktuelle WaitHandle ein Signal empfängt, wobei eine 32-Bit-Ganzzahl mit Vorzeichen zum Angeben des Zeitintervalls verwendet und angegeben wird, ob die Synchronisierungsdomäne vor dem Wartevorgang verlassen werden soll.

Namespace:  System.Threading
Assembly:  mscorlib (in mscorlib.dll)

public virtual bool WaitOne(
	int millisecondsTimeout,
	bool exitContext
)

Parameter

millisecondsTimeout
Typ: System.Int32
Die Wartezeit in Millisekunden oder Timeout.Infinite (-1) für Warten ohne Timeout.
exitContext
Typ: System.Boolean
true , um die Synchronisierungsdomäne für den Kontext vor dem Wartevorgang (sofern in einem synchronisierten Kontext) zu verlassen und diese anschließend erneut abzurufen, andernfalls false.

Rückgabewert

Typ: System.Boolean
true , wenn die aktuelle Instanz ein Signal empfängt, andernfalls false.

AusnahmeBedingung
ObjectDisposedException

Die aktuelle Instanz wurde bereits freigegeben.

ArgumentOutOfRangeException

millisecondsTimeout ist eine negative Zahl, aber nicht -1. Der Wert -1 gibt einen Endlostimeout an.

AbandonedMutexException

Die Wartezeit wurde abgeschlossen, weil ein Thread beendet wurde, ohne einen Mutex freizugeben. Diese Ausnahme wird unter Windows 98 oder Windows Millennium Edition nicht ausgelöst.

InvalidOperationException

Die aktuelle Instanz ist ein transparenter Proxy für ein WaitHandle in einer anderen Anwendungsdomäne.

Wenn millisecondsTimeout 0 (null) ist, wird die Methode nicht blockiert. Sie testet den Zustand des WaitHandles und sofort beendet.

AbandonedMutexException ist neu in .NET Framework, Version 2.0. In früheren Versionen wurde von der WaitOne-Methode true zurückgegeben, wenn ein Mutex abgebrochen wurde. Ein verwaister Mutex ist häufig ein Hinweis auf einen schwerwiegenden Fehler im Code. Wenn es sich um einen systemweiten Mutex handelt, kann dies darauf hinweisen, dass eine Anwendung plötzlich beendet wurde (z. B. über den Windows Task-Manager). Die Ausnahme enthält nützliche Informationen für das Debuggen.

Der Aufrufer dieser Methode blockiert, bis die aktuelle Instanz ein Signal empfängt oder ein Timeout auftritt. Verwenden Sie diese Methode, um so lange zu blockieren, bis eine WaitHandle-Klasse ein Signal von einem anderen Thread empfängt, z. B. ein Signal, das nach Abschluss einer asynchronen Operation generiert wird. Weitere Informationen finden Sie unter der IAsyncResult-Schnittstelle.

Überschreiben Sie diese Methode, wenn Sie das Verhalten von abgeleiteten Klassen anpassen möchten.

Hinweise zum Beenden des Kontexts

Der exitContext-Parameter hat keine Auswirkungen, sofern die WaitOne-Methode nicht aus einem verwalteten Nichtstandardkontext heraus aufgerufen wird. Dies kann auftreten, wenn sich der Thread innerhalb eines Aufrufs einer Instanz von einer von der ContextBoundObject-Klasse abgeleiteten Klasse befindet. Auch wenn derzeit eine Methode für eine Klasse ausgeführt wird, die nicht von ContextBoundObject abgeleitet ist, z. B. String, kann dies in einem Nichtstandardkontext erfolgen, wenn sich auf dem Stapel in der aktuellen Anwendungsdomäne ein ContextBoundObject befindet.

Wenn der Code in einem Nichtstandardkontext ausgeführt wird und Sie für exitContext den Wert true angeben, führt dies dazu, dass der Thread vor der Ausführung der WaitOne-Methode den Nichtstandardkontext verlässt (d. h. in den Standardkontext übergeht). Nachdem der Aufruf der WaitOne-Methode vollständig ausgeführt wurde, kehrt der Thread zum ursprünglichen Nichtstandardkontext zurück.

Dies kann nützlich sein, wenn die kontextgebundene Klasse über ein SynchronizationAttribute verfügt. In diesem Fall werden alle Aufrufe von Membern der Klasse automatisch synchronisiert, und die Synchronisierungsdomäne ist der gesamte Codeabschnitt für die Klasse. Wenn der Code in der Aufrufliste eines Members die WaitOne-Methode aufruft und true für exitContext angibt, beendet der Thread die Synchronisierungsdomäne und lässt zu, dass ein Thread fortfährt, der bei einem Aufruf eines Members des Objekts blockiert wird. Wenn die WaitOne-Methode zurückgegeben wird, muss der Thread, der den Aufruf ausgeführt hat, warten, bis er die Synchronisierungsdomäne erneut eingeben kann.

Im folgenden Beispiel wird gezeigt, wie sich die WaitOne(Int32, Boolean)-Methodenüberladung verhält, wenn sie innerhalb einer Synchronisierungsdomäne aufgerufen wird. Zuerst wartet ein Thread mit exitContext, der auf false festgelegt ist, und blockiert, bis das Wartetimeout abgelaufen ist. Ein zweiter Thread wird ausgeführt, nachdem der erste Thread beendet wurde. Der Thread wartet, wobei exitContext auf true festgelegt ist. Der Aufruf, um den Wait-Handle zu signalisieren, für diesen zweiten Thread wird nicht blockiert, und der Thread wird vor dem Wartevorgangstimeout abgeschlossen.


using System;
using System.Threading;
using System.Runtime.Remoting.Contexts;

[Synchronization(true)]
public class SyncingClass : ContextBoundObject
{
    private EventWaitHandle waitHandle;

    public SyncingClass()
    {
         waitHandle =
            new EventWaitHandle(false, EventResetMode.ManualReset);
    }

    public void Signal()
    {
        Console.WriteLine("Thread[{0:d4}]: Signalling...", Thread.CurrentThread.GetHashCode());
        waitHandle.Set();
    }

    public void DoWait(bool leaveContext)
    {
        bool signalled;

        waitHandle.Reset();
        Console.WriteLine("Thread[{0:d4}]: Waiting...", Thread.CurrentThread.GetHashCode());
        signalled = waitHandle.WaitOne(3000, leaveContext);
        if (signalled)
        {
            Console.WriteLine("Thread[{0:d4}]: Wait released!!!", Thread.CurrentThread.GetHashCode());
        }
        else
        {
            Console.WriteLine("Thread[{0:d4}]: Wait timeout!!!", Thread.CurrentThread.GetHashCode());
        }
    }
}

public class TestSyncDomainWait
{
    public static void Main()
    {
        SyncingClass syncClass = new SyncingClass();

        Thread runWaiter;

        Console.WriteLine("\nWait and signal INSIDE synchronization domain:\n");
        runWaiter = new Thread(RunWaitKeepContext);
        runWaiter.Start(syncClass);
        Thread.Sleep(1000);
        Console.WriteLine("Thread[{0:d4}]: Signal...", Thread.CurrentThread.GetHashCode());
        // This call to Signal will block until the timeout in DoWait expires.
        syncClass.Signal();
        runWaiter.Join();

        Console.WriteLine("\nWait and signal OUTSIDE synchronization domain:\n");
        runWaiter = new Thread(RunWaitLeaveContext);
        runWaiter.Start(syncClass);
        Thread.Sleep(1000);
        Console.WriteLine("Thread[{0:d4}]: Signal...", Thread.CurrentThread.GetHashCode());
        // This call to Signal is unblocked and will set the wait handle to
        // release the waiting thread.
        syncClass.Signal();
        runWaiter.Join();
    }

    public static void RunWaitKeepContext(object parm)
    {
        ((SyncingClass)parm).DoWait(false);
    }

    public static void RunWaitLeaveContext(object parm)
    {
        ((SyncingClass)parm).DoWait(true);
    }
}

// The output for the example program will be similar to the following:
//
// Wait and signal INSIDE synchronization domain:
//
// Thread[0004]: Waiting...
// Thread[0001]: Signal...
// Thread[0004]: Wait timeout!!!
// Thread[0001]: Signalling...
//
// Wait and signal OUTSIDE synchronization domain:
//
// Thread[0006]: Waiting...
// Thread[0001]: Signal...
// Thread[0001]: Signalling...
// Thread[0006]: Wait released!!!


.NET Framework

Unterstützt in: 4.5, 4, 3.5, 3.0, 2.0, 1.1, 1.0

.NET Framework Client Profile

Unterstützt in: 4, 3.5 SP1

Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core-Rolle wird nicht unterstützt), Windows Server 2008 R2 (Server Core-Rolle wird mit SP1 oder höher unterstützt; Itanium wird nicht unterstützt)

Es werden nicht alle Versionen sämtlicher Plattformen von .NET Framework unterstützt.. Eine Liste der unterstützten Versionen finden Sie unter Systemanforderungen für .NET Framework.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft