windows WaitForMultipleObjects / MsgWaitForMultipleObjects difference

Question

I'm trying to understand the difference between MsgWaitFor and WaitFor functions.

1) I understand that the MsgWaitFor is running under a message loop, while the WaitFor does not?
2) Does the MsgWaitFor functions is better for an application that need to receive a sequence of events in a row? Does Windows queues the messages, so the application won't miss any events? Say application wants to receive event A and B which happens frequently. The application will open a thread:

while (1) {
  ret = WaitForMultipleObjects(...); // wait for events A and B
  if (ret == WAIT_OBJECT_0) {
    process_event();
  }
}

The question is, when the thread is busy with processing, meaning it is currently not blocked by WaitForMultipleObjects. How can the thread avoid missing the events until it goes back to waiting?

Answer 1

I'm trying to understand the difference between MsgWaitFor and WaitFor functions.

The main difference is MsgWaitForMultipleObjects/MsgWaitForMultipleObjectsEx can wait for messages (in message queue) in addition to the following object types:

• Change notification
• Console input
• Event
• Memory resource notification
• Mutex
• Process
• Semaphore
• Thread
• Waitable timer

So if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than WaitForMultipleObjectsEx.

The question is, when the thread is busy with processing, meaning it is currently not blocked by WaitForMultipleObjects. How can the thread avoid missing the events until it goes back to waiting?

Message has queue and the queue has a length (10,000 posted messages). So when processing messages too slow, the PostMessage may fails with ERROR_NOT_ENOUGH_QUOTA. But for receiver side, you will not miss messages and you can handle queued messages one by one.

Event object has no queue and it has two state: signaled and nonsignaled. Setting an event that is already set has no effect. So if this is a manual-reset event object, it remains signaled until it is set explicitly to the nonsignaled state by the ResetEvent function. There may be a miss at setting side instead of checking side.

Answer 2

both MsgWaitForMultipleObjects[Ex] and WaitForMultipleObjects[Ex] internal call the same api - KeWaitForMultipleObjects

different in - MsgWaitForMultipleObjects[Ex] add event (in front, at 0 index) to array of object handles. because KeWaitForMultipleObjects have restriction of maximum number of objects to MAXIMUM_WAIT_OBJECTS, the same restriction have and WaitForMultipleObjects[Ex] and MAXIMUM_WAIT_OBJECTS - 1 for MsgWaitForMultipleObjects[Ex] (because used additional +1 event object)

exist only 2 WAIT_TYPE - either WaitAll, indicating that all of the specified objects must attain a signaled state before the wait is satisfied; or WaitAny, indicating that any one of the objects must attain a signaled state before the wait is satisfied.

when we wait for object to be signaled - not important will be object in signal state before or after we begin wait for it. we not miss signal state anyway. of course if we manually not reset object to not signal state again. but this already question of program logic and not related to wait api

sequence of events in a row

not exist any sequence here. every object can be in 2 states (signaled or not) and we can wait for all or any objects in signaled state. if you wait for any - which object first will be signaled depend from concrete situation.

Does Windows queues the messages, so the application won't miss any events?

no any messages at all. exist only objects with DISPATCHER_HEADER (look in wdm.h) inside it. wait api check SignalState of DISPATCHER_HEADER and if it set already - return control (if we wait for single object or any object of course). if not - insert thread to WaitListHead (this is double linked list, where can be multiple threads, which wait for this object, and begin from win8 - WaitCompletionPacket's objects. when object go to signal state (SignalState set to non zero). system wake first (SynchronizationEvent) or all (NotificationEvent, other object types) waiting threads in WaitListHead (again based on waitall or wait any). in case WaitCompletionPacket - it queued to iocp

so again - we nothing miss (if not reset object by self again)