The Win32 API provides a set of wait functions to allow a thread to block its own execution. There are three types of wait functions:
·single-object
·multiple-object
·alertable
The wait functions do not return until the specified criteria have been met. The type of wait function determines the set of criteria used. When a wait function is called, it checks whether the wait criteria have been met. If the criteria have not been met, the calling thread enters an efficient wait state, consuming very little processor time while waiting for the criteria to be met.
Single-object Wait Functions
The SignalObjectAndWait, WaitForSingleObject, and WaitForSingleObjectEx functions require a handle of one synchronization object. These functions return when one of the following occurs:
·The specified object is in the signaled state.
·The time-out interval elapses. The time-out interval can be set to INFINITE to specify that the wait will not time out.
The SignalObjectAndWait function enables the calling thread to atomically set the state of an object to signaled and wait for the state of another object to be set to signaled.
Multiple-object Wait Functions
The WaitForMultipleObjects, WaitForMultipleObjectsEx, MsgWaitForMultipleObjects, and MsgWaitForMultipleObjectsEx functions enable the calling thread to specify an array containing one or more synchronization object handles. These functions return when one of the following occurs:
·The state of any one of the specified objects is set to signaled or the states of all objects have been set to signaled. You control whether one or all of the states will be used in the function call.
·The time-out interval elapses. The time-out interval can be set to INFINITE to specify that the wait will not time out.
The MsgWaitForMultipleObjects and MsgWaitForMultipleObjectsEx function allow you to specify input event objects in the object handle array. This is done when you specify the type of input to wait for in the thread's input queue.
For example, a thread could use MsgWaitForMultipleObjects to block its execution until the state of a specified object has been set to signaled and there is mouse input available in the thread's input queue. The thread can use the GetMessage or PeekMessage function to retrieve the input.
When waiting for the states of all objects to be set to signaled, these multiple-object functions do not modify the states of the specified objects until the states of all objects have been set signaled. For example, the state of a mutex object can be signaled, but the calling thread does not get ownership until the states of the other objects specified in the array have also been set to signaled. In the meantime, some other thread may get ownership of the mutex object, thereby setting its state to nonsignaled.
Alertable Wait Functions
The MsgWaitForMultipleObjectsEx, SignalObjectAndWait, WaitForMultipleObjectsEx, and WaitForSingleObjectEx functions differ from the other wait functions in that they can optionally perform an alertable wait operation. In an alertable wait operation, the function can return when the specified conditions are met, but it can also return if the system queues an I/O completion routine or an APC for execution by the waiting thread. For more information about alertable wait operations and I/O completion routines, see Synchronization and Overlapped Input and Output. For more information about APCs, see Asynchronous Procedure Calls.
Wait Functions and Synchronization Objects
Before returning, a wait function can modify the states of some types of synchronization objects. Modification occurs only for the object or objects whose signaled state caused the function to return. A wait function can modify the states of synchronization objects as follows:
·The count of a semaphore object decreases by one, and the state of the semaphore is set to nonsignaled if its count is zero.
·The states of mutex, auto-reset event, and change-notification objects are set to nonsignaled.
·The state of a synchronization timer is set to nonsignaled.
·The states of manual-reset event, manual-reset timer, process, thread, and console input objects are not affected by a wait function.
Wait Functions and DDE
You have to be careful when using the wait functions and DDE. If a thread creates any windows, it must process messages. DDE sends messages to all windows in the system. If you have a thread that uses a wait function with no time-out interval, the system will deadlock. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than the other wait functions.