Is there a difference in performance when multi-threading developed with win32 event objects (CreateEvent) or with thread window message queue. Both should use some kind of WaitFor... calls. My own code almost completely based on event, but maybe I lose something when don't use messages.
+3
A:
If you are worried about the performance difference between thread messages, and kernel events, then you should probably not use thread messages.
Win32 thread message queues are a mechanism developed originally for Windows 16 - when there were no threads. They've grown to handle Win32's threading model, but under the covers they are rather complex beasts.
This has pro's and con's. The cons are, quite simply, that they are slower, and have a lot more limits, than other forms of inter thread synchronization and comms. For starters, because lots of pieces of windows code (MessageBox, DoDragDrop etc) implement modal message loops - there are a lot of times when thread messages can be lost. Its important not to use those APIs from threads that are meant to be receiving thread messages.*1 There are also limits to the size of a message queue before it starts to drop messages, and the thread messaging APIs (GetMessage) do not cause the thread to enter an alertable state (so you cannot use QueueUserAPC).
The pro' for thread messages are - as long as their limits are respected - they are a very reliable pre-made wheel that serializes calls to a thread. If you find yourself implementing a queueing mechanism for a non UI worker thread, why re-invent a well tested wheel - use the pre-built message queue.
*1 This includes most implementations of debugging macro's like ASSERT that will pop up a message box.
Chris Becke
2009-12-11 12:35:45