Wait Handles

Updated: April 2011

The WaitHandle class encapsulates Win32 synchronization handles, and is used to represent all synchronization objects in the runtime that allow multiple wait operations. For a comparison of wait handles with other synchronization objects, see Overview of Synchronization Primitives.

The WaitHandle class itself is abstract. In addition to derived classes, it has a number of static methods that enable waiting on multiple events. Classes derived from WaitHandle include the following:

Because the WaitHandle class derives from MarshalByRefObject, these classes can be used to synchronize the activities of threads across application domain boundaries.

Threads can block on an individual wait handle by calling the instance method WaitOne. In addition, the WaitHandle class has overloaded static methods for waiting until all of a specified set of wait handles have been signaled (WaitAll), or waiting until any one of a specified set of wait handles has been signaled (WaitAny). The overloads of these methods provide timeout intervals for abandoning the wait, and the opportunity to exit a synchronization context before entering the wait, allowing other threads to use the synchronization context.

In the .NET Framework version 2.0, wait handles also have the static SignalAndWait method, which allows a thread to signal one wait handle and immediately wait on another.

The derived classes of WaitHandle differ in their thread affinity. Event wait handles (EventWaitHandle, AutoResetEvent, and ManualResetEvent) and semaphores do not have thread affinity. Any thread can signal an event wait handle or semaphore. Mutexes, on the other hand, do have thread affinity. The thread that owns a mutex must release it; an exception is thrown if a thread calls the ReleaseMutex method on a mutex that it does not own.




April 2011

Correction: The WaitHandle.SignalAndWait method is not atomic.

Customer feedback.

Community Additions