Why doesn't message pump/loop block all threads?
-
Hi I have a basic question about classic message loop of Win32 programs.
while (GetMessage(&msg, NULL, 0, 0)) { if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } }Why doesn't this message loop take all processor time? I also increment the priority level:
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
In another MFC application i created a new thread with infinite loop( I mean in function there is only "infinite while loop", as classic win32 message loop) and also set priority to THREAD_PRIORITY_HIGHEST. That loop blocked all other threads. But why doesn't win32 message loop block other threads? Thanks.
-
Hi I have a basic question about classic message loop of Win32 programs.
while (GetMessage(&msg, NULL, 0, 0)) { if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } }Why doesn't this message loop take all processor time? I also increment the priority level:
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
In another MFC application i created a new thread with infinite loop( I mean in function there is only "infinite while loop", as classic win32 message loop) and also set priority to THREAD_PRIORITY_HIGHEST. That loop blocked all other threads. But why doesn't win32 message loop block other threads? Thanks.
sawerr wrote:
Why doesn't this message loop take all processor time?
Because GetMessage() blocks until a message is available in the queue. If you want it to spin and consume nearly all of the CPU time for a core, use PeekMessage() instead of GetMessage(). Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
sawerr wrote:
Why doesn't this message loop take all processor time?
Because GetMessage() blocks until a message is available in the queue. If you want it to spin and consume nearly all of the CPU time for a core, use PeekMessage() instead of GetMessage(). Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Mark Salsbery wrote:
Because GetMessage() blocks until a message is available in the queue.
Is this something like that: GetMessage() { while(true) { if(queue == EMPTY) Sleep(100); } }
We all would hope the Windows kernel is event driven, and not polling all the time. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
We all would hope the Windows kernel is event driven, and not polling all the time. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
Mark Salsbery wrote:
Because GetMessage() blocks until a message is available in the queue.
Is this something like that: GetMessage() { while(true) { if(queue == EMPTY) Sleep(100); } }
sawerr wrote:
Is this something like that
No, not at all. Within GetMessage(), there's something like
GetMessage(...)
{
// wait for a new message to be queued
WaitForSingleObject(QueuedMessageEvent)return message to caller}
If the event isn't signalled when GetMessage() is called, WaitForSingleObject() puts the thread in a "wait state", a state where the thread is almost completely suspended - it uses VERY little CPU time. Using Sleep as you've shown is extremely inefficient. :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Hi,
GetMessage() {
if(queue == EMPTY) {
queue.AddWaiter(currentThread);
SwitchToForemostReadyThread();
}
return queue.RemoveMsg();
}PutMessage(Message msg) {
queue.AddMsg(msg);
if(queue.HasWaitersWithHigherPriority(myPriority)) {
Thread thread=queue.RemoveWaiter();
SwitchToThread(thread);
}
}Not a single busy-wait or polling loop! The heart in the matter is the SwitchTo...Thread() methods save the current thread state on its stack, and load another thread's state from its stack, effectively performing a "thread switch". :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
sawerr wrote:
Is this something like that
No, not at all. Within GetMessage(), there's something like
GetMessage(...)
{
// wait for a new message to be queued
WaitForSingleObject(QueuedMessageEvent)return message to caller}
If the event isn't signalled when GetMessage() is called, WaitForSingleObject() puts the thread in a "wait state", a state where the thread is almost completely suspended - it uses VERY little CPU time. Using Sleep as you've shown is extremely inefficient. :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: