windows - 关于消息循环的问题

Question

有个问题困扰了我很久。

简短版:

Windows Message Loop 的工作范式是什么？

详细版本:

当我们启动一个 Windows 应用程序(不是控制台应用程序)时，我们可以通过鼠标或键盘与它进行交互。该应用程序从其消息队列中检索代表我们 Action 的各种消息。 Windows 负责收集我们的操作并将消息正确地馈送到该队列中。但这种情况是否意味着 Windows 必须无限地运行？

我认为 Windows 调度程序 应该一直在运行。它可能会在预定义的时间间隔内由时间中断调用。当调度程序被时间中断触发时，它将当前线程切换到下一个挂起的线程。单个线程只能通过 GetMessage() 获取其消息计划运行时间。

我想知道如果只有一个 Windows 应用程序在运行，这个应用程序是否有更多机会获取它的消息？

更新 - 1(2010 年 11 月 22 日上午 9:59)

这是我的最新发现:

根据 第7章线程优先级

...For example, if your process' primary thread calls GetMessage() and the system sees that no messages are pending, the system suspends your porcess' thread, relinquishes the remainder of the thread's time slice, and immediately assigns the CPU to another waiting thread.

If no messages show up for GetMessage to retrieve, the process' primary thread stays suspended and is never assigned to a CPU. However, when a message is placed in the thread's queue, the system knows that the thread should no longer be suspended and assigns the thread to a CPU if no higher-priority threads need to execute.

我目前的理解是:

为了让系统知道消息何时被放入线程的队列中，我可以想到两种可能的方法:

1 - 集中式方法:系统负责始终检查每个线程的队列。甚至那个线程也因为缺少消息而被阻塞。如果有任何消息可用，系统会将该线程的状态更改为可调度。但在我看来，这种检查可能会对系统造成真正的负担。

2 - 分布式方法:系统不会检查每个线程的队列。当线程调用 GetMessage 发现没有可用消息时，系统只会将线程状态更改为阻塞状态，从而不再可调度。将来无论是谁将消息放入阻塞线程的队列中，都是这个“谁”(而不是系统)负责将线程的状态从阻塞 到 ready (或任何状态)。 所以这个线程被系统取消了调度资格，在GetMessage方面被其他人重新授予了资格。系统关心的只是调度可运行线程。系统不关心这些可调度线程来自哪里。这种方法将避免方法1中的负担，从而避免可能的瓶颈。

其实这里的重点是，线程的状态是怎么变化的？我不确定它是否真的是方法 2 中所示的分布式范式，但它会是一个不错的选择吗？

Answer 1

应用程序在它们的消息循环中调用 GetMessage()。如果消息队列为空，则进程将阻塞，直到有另一条消息可用。因此，GetMessage 是一种进程告诉 Windows 它目前没有任何事情要做的方式。