Partager via


WaitForMultipleObjects

A version of this page is also available for

Windows Embedded CE 6.0 R3

4/8/2010

This function returns a value when either any one of the specified objects is in the signaled state, or the time-out interval elapses.

Syntax

DWORD WaitForMultipleObjects(
  DWORD nCount,
  CONST HANDLE* lpHandles,
  BOOL fWaitAll,
  DWORD dwMilliseconds
);

Parameters

  • nCount
    [in] Specifies the number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS.
  • lpHandles
    [in] Pointer to an array of object handles. For a list of the object types whose handles can be specified, see the Remarks section. The array can contain handles of objects of different types.
  • fWaitAll
    [in] Specifies the wait type. This parameter must be set to FALSE. This causes function to return when the state of any one of the objects set to is signaled. The return value indicates the object whose state caused the function to return.
  • dwMilliseconds
    [in] Specifies the time-out interval in milliseconds. The function returns if the interval elapses, even if the conditions specified by the bWaitAll parameter are not met. If dwMilliseconds is zero, the function tests the states of the specified objects and returns immediately. If dwMilliseconds is INFINITE, the function's time-out interval never elapses.

Return Value

If the function succeeds, the return value indicates the event that caused the function to return. The following table shows possible values.

Value Description

WAIT_OBJECT_0 to (WAIT_OBJECT_0 + nCount –1)

The return value minus WAIT_OBJECT_0 indicates the lpHandles array index of the object that satisfied the wait. If more than one object became signaled during the call, this is the array index of the signaled object with the smallest index value of all the signaled objects.

WAIT_TIMEOUT

The time-out interval elapsed and the condition specified by the fWaitAll parameter is not satisfied.

WAIT_FAILED indicates failure. To get extended error information, call GetLastError.

Remarks

Windows CE 1.0 through 2.12 do not support waiting for semaphores, change notification objects, input, and timers. Windows CE 3.0 and later supports waiting for semaphores.

For Windows CE 1.0 and 1.01, this function cannot wait on process or thread handles.

Two threads cannot wait on a single interrupt event.

A thread cannot wait on an interrupt event and a normal event at the same time.

The WaitForMultipleObjects function determines whether the wait criteria were met. If the criteria were not met, the calling thread enters an efficient wait state, consuming very little processor time while waiting for the criteria to be met. The time-out value needs to be a positive number between zero and 0x7FFFFFFF. The maximum time-out value not equal to infinity is 0x7FFFFFFF. The infinite time-out value is 0xFFFFFFFF. Any time-out value between 0x7FFFFFFF and 0xFFFFFFFF — that is, values from 0x80000000 through 0xFFFFFFFE — is equivalent to 0x7FFFFFFF. If you need a bigger time-out value than the maximum of 0x7FFFFFFF, use the value for infinity (0xFFFFFFFF).

Before returning, a wait function modifies the state of some types of synchronization objects. Modification occurs only for the object or objects whose signaled state caused the function to return. When fWaitAll is FALSE, and multiple objects are in the signaled state, the function chooses one of the objects to satisfy the wait; the states of the objects not selected are unaffected. The WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

  • Event
  • Mutex
  • Process
  • Thread
  • Semaphore

Use caution when calling the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. A thread that uses a wait function with no time-out interval may cause the system to become deadlocked. For example, the Dynamic Data Exchange (DDE) protocol and the COM function CoInitialize both indirectly create windows that can cause a deadlock. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than WaitForMultipleObjects.

Each object type, such as memory maps, semaphores, events, message queues, mutexes, and watchdog timers, has its own separate namespace. Empty strings ("") are handled as named objects. On Windows desktop-based platforms, synchronization objects all share the same namespace.

WaitForMultipleObjects cannot be used to wait for any event that is registered for an interrupt. If WaitForMultipleObjects is used incorrectly for this type of event, it would result in an operation in the kernel that would have pre-emption turned off, which will diminish real-time performance. To wait for a registered interrupt event, WaitForSingleObject should be used instead of WaitForMultipleObjects.

Requirements

Header winbase.h
Library Nk.lib
Windows Embedded CE Windows CE 1.01 and later
Windows Mobile Windows Mobile Version 5.0 and later

See Also

Reference

Synchronization Functions
WaitForSingleObject
CreateEvent
CreateMutex
CreateProcess
CreateThread
PulseEvent
ResetEvent
SetEvent

Other Resources

MsgWaitForMultipleObjects
MsgWaitForMultipleObjectsEx
CreateFile