哪个更快：SetEvent、SendMessage、PostMessage
环境：Win32、C/C++
所有三 (3) 都可用于线程向 main() 发出信号，表明它已完成操作。
但哪一个是所有信号中最快的呢？
唔...
Environment: Win32, C/C++
All three (3) can be used for a thread to signal to main() that it has completed an operation for example.
But which one is the fastest signal of all?
hmm...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
所有三个选项都需要线程上下文切换来实际向接收线程发出信号。 上下文切换的开销很可能会压倒任何 API 中处理成本的差异。
该选择可能最好由接收线程的性质驱动，例如它是否是 UI 线程，和/或它是否执行消息循环。 也就是说，一些细节包括：
SendMessage 很有用。 发送线程将阻塞，直到接收者处理消息。 但它可能会在这段时间内处理未排队的消息。 该逻辑可能会减慢速度，因为可能涉及额外的上下文切换，从而使 SendMessage 成为三者中最慢的。
PostMessage 在收件人位于消息循环内。 与 SendMessage 的区别在于，它不会等待收件人处理消息，因此产生的开销较少。
SetEvent 在接收线程时很有用可以等待事件对象，例如使用 WaitForSingleObject ()。 它不会产生封送或消息处理开销，并且可能比其他方法响应更快。
All three options require a thread context switch to actually signal the receiving thread. It's quite likely that the overhead of the context switch will overwhelm any difference in processing cost in any of the APIs.
The choice is likely best driven by the nature of the receiving thread, e.g. is it a UI thread, and/or does it carry out a message loop. That said, some fine detail includes:
SendMessage is useful when the receiving thread is a UI thread, churning inside a message loop. The sending thread will block until the recipient processes the message. But it may handle unqueued messages during that time. That logic could potentially slow things down, as additional context switches may be involved, making SendMessage the slowest of the three.
PostMessage is also useful when the recipient is inside a message loop. The difference from SendMessage is that it doesn't wait for the recipient to process the message, thus incurring less overhead.
SetEvent is useful when the receiving thread can wait on an event object, e.g. with WaitForSingleObject(). It incurs no marshaling or message processing overhead, and is likely to respond quicker than the others.
SetEvent 是迄今为止最快、最简单的，但它携带的信息也最少。 基本上它所能说的就是发生了一些事情（事件被发出信号），仅此而已。
SetEvent is by far the fastest and the simplest but it also can carry the least information. Basically all it can say is that something happened (the event was signaled) nothing more.
还没有检查过，但（假设你有人在等待该对象）我会说 SetEvent、SendMessage 和最后的 PostMessage。
编辑：上面的原因很简单，SendMessage 是同步的，PostMessage 是异步的。 我不确定 SetEvent，但我假设它会触发等待事件的事件，而不必等待消息泵传递消息。 想想发送或发布可能并不重要，只是发送方是否会等待的问题。 内部处理可能是相同的。
但是，通常情况下，您不会使用发布或发送消息来向另一个线程发送信号。
Have not checked but (assuming you have someone waiting for the object) I would say SetEvent, SendMessage and finally PostMessage.
Edit: The reasoning behind the above is simply that SendMessage is synchronous and PostMessage is asynchronous. I am not sure about the SetEvent but I would assume it to trigger something waiting for the event without having to wait for the message pump delivering the message. Thinking about it sending or posting probably doesn't matter, it is just a matter of if the sending party will wait or not. The internal processing is probably identical.
However, neither posting nor sending a message is normally what you would use to send a signal to another thread.
如果您查看 MsgWaitForMultipleObjects 与 WaitForMultipleObjects，您会发现 MsgWaitForMultipleObjects 的最大等待对象比 WaitForMultipleObjects 少 1，这意味着存在隐藏的“消息事件”，因此消息将具有事件 + 消息传递的开销
If you look at MsgWaitForMultipleObjects vs WaitForMultipleObjects, you will see that the maximum wait objects for MsgWaitForMultipleObjects is one less than WaitForMultipleObjects meaning that there is a hidden "on message event" so a message will have the overhead of a event + the message passing