Windows消息泵内部工作机制及非队列消息处理疑问

基础Windows应用消息循环示例 #

MSG msg;
while(GetMessage(&msg, NULL, 0, 0) > 0)
{
    DispatchMessage(&msg);
}

假设程序已实现WindowProc回调函数用于处理消息（本文不聚焦WindowProc本身）。

一、GetMessage/PeekMessage的阻塞与唤醒逻辑 #

GetMessage的核心逻辑围绕线程挂起与唤醒展开：

• 当线程消息队列中没有符合条件的消息时，GetMessage会将当前线程切换至等待状态，此时线程不占用CPU资源。
• Windows内核为每个线程的消息队列关联了一个事件对象，当有新消息（队列消息或触发非队列消息的请求）到来时，内核会触发该事件，唤醒挂起的线程。
• 线程被唤醒后，GetMessage会重新检查队列，取出符合条件的消息返回，线程继续执行后续的DispatchMessage调用。

而PeekMessage是非阻塞的：无论队列是否有消息，它都会立刻返回——有消息则取出，无消息直接返回0，不会挂起线程。

二、队列消息处理时非队列消息到来的行为 #

先明确两类消息的本质：

• 队列消息：如WM_PAINT、WM_KEYDOWN、WM_TIMER，会被存入线程消息队列等待分发。
• 非队列消息：如SendMessage发送的消息，不会进入队列，直接触发目标窗口的WindowProc调用。

场景1：GetMessage正在读取队列消息时 #

此时Windows会中断GetMessage的队列读取操作，优先调用目标窗口的WindowProc处理这条非队列消息，处理完成后，GetMessage才会继续从队列中读取消息。

场景2：队列消息正处于分发（执行WindowProc）时 #

如果非队列消息发往当前线程的窗口，Windows会抢占当前WindowProc的执行流程，先处理这条非队列消息，处理完成后再回到原队列消息的WindowProc继续执行——这是Windows消息系统的优先级特性，非队列消息优先级高于队列消息。

三、非队列消息的处理流程与并发问题 #

非队列消息的处理完全绕开线程消息队列，流程分两种情况：

1. 同线程发送：调用SendMessage时，直接同步调用目标窗口的WindowProc，处理完成后才返回给发送方，不存在延后处理的问题。
2. 跨线程发送：发送方线程进入等待状态，Windows会将消息存入目标线程内部维护的非队列消息等待列表，同时唤醒目标线程的GetMessage。目标线程被唤醒后，GetMessage会优先处理完所有待处理的非队列消息，再去处理普通队列消息。

如果第一条非队列消息尚未处理完成，又有新的非队列消息到来：

• 同线程发送的消息会直接嵌套调用WindowProc（比如在处理A消息的WindowProc里调用SendMessage发B消息，会先处理B，再回到A）。
• 跨线程发送的消息会被加入目标线程的非队列消息等待列表，等当前非队列消息处理完成后，下一次GetMessage唤醒时会优先处理这条新消息。

四、基于同步原语的简化实现示例 #

Windows消息队列的核心依赖事件对象实现线程挂起/唤醒，配合临界区保护队列的并发访问。以下是极简模拟实现：

#include <windows.h>
#include <queue>

// 模拟线程消息队列
std::queue<MSG> g_msgQueue;
// 保护队列的临界区
CRITICAL_SECTION g_csQueue;
// 用于唤醒线程的事件
HANDLE g_hMsgEvent;

// 模拟GetMessage
BOOL MyGetMessage(MSG* pMsg)
{
    EnterCriticalSection(&g_csQueue);
    // 队列空则释放临界区，等待事件触发
    while (g_msgQueue.empty())
    {
        LeaveCriticalSection(&g_csQueue);
        WaitForSingleObject(g_hMsgEvent, INFINITE);
        EnterCriticalSection(&g_csQueue);
    }
    // 取出队列头部消息
    *pMsg = g_msgQueue.front();
    g_msgQueue.pop();
    LeaveCriticalSection(&g_csQueue);
    return TRUE;
}

// 模拟投递队列消息（对应PostMessage）
void MyPostMessage(const MSG& msg)
{
    EnterCriticalSection(&g_csQueue);
    g_msgQueue.push(msg);
    LeaveCriticalSection(&g_csQueue);
    // 触发事件唤醒等待的线程
    SetEvent(g_hMsgEvent);
}

// 初始化消息系统
void InitMsgSystem()
{
    InitializeCriticalSection(&g_csQueue);
    g_hMsgEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
}

可视化逻辑说明 #

1. 线程调用MyGetMessage，发现队列空，释放临界区后进入等待状态，线程挂起。
2. 其他线程调用MyPostMessage，将消息加入队列后触发事件，唤醒挂起的线程。
3. 线程被唤醒后回到MyGetMessage，取出消息返回，继续执行后续的消息分发逻辑。
4. 非队列消息会直接绕过队列，在MyGetMessage的等待间隙或队列处理间隙，同步调用WindowProc完成处理。

五、核心疑问：SendMessage为何需要GetMessage才能接收？ #

首先纠正误解：同线程发送的SendMessage不需要GetMessage参与，直接调用WindowProc；只有跨线程发送的SendMessage才依赖目标线程的GetMessage。

跨线程场景下，Windows无法强行在目标线程的上下文执行代码（线程上下文只能由自身代码切换），因此需要依赖目标线程的消息循环：

• 当目标线程因GetMessage挂起时，Windows会触发事件唤醒它，GetMessage被唤醒后会优先处理这条非队列消息（直接调用WindowProc），处理完成后再继续处理队列消息。
• 如果目标线程没有运行消息循环（未调用GetMessage/PeekMessage），跨线程的SendMessage请求会永远无法被处理，发送方线程会一直等待甚至死锁。

内容的提问来源于stack exchange，提问作者ScienceDiscoverer