c++ - 更多线程，更好的性能？

Question

当我编写一个消息驱动的应用程序时。与标准 Windows 应用程序非常相似，只是它广泛使用消息传递进行内部操作，关于线程的最佳方法是什么？

据我所知，基本上有三种方法(如果您有任何其他设置，请分享):

1. 让一个线程处理所有消息。
2. 为不同的消息类型(常规、UI、网络等...)提供不同的线程
3. 拥有共享和处理单个消息队列的多个线程。

那么，这三者之间会有什么显着的性能差异吗？以下是一些一般性的想法:显然，后两种选择受益于有多个处理器的情况。另外，如果任何线程正在等待外部事件，其他线程仍然可以处理不相关的消息。但忽略这一点，似乎多线程只会增加开销(线程切换，更不用说更复杂的同步情况)。

还有一个问题:您会推荐在标准 Windows 消息系统上实现这样一个系统，还是实现一个单独的队列机制，为什么？

Answer 1

线程模型的具体选择应由您要解决的问题的性质决定。不一定有单一的“正确”方法来为此类应用程序设计线程模型。但是，如果我们采用以下假设:

1. 消息频繁到达
2. 消息是独立的，不会过度依赖共享资源
3. 希望尽快回复到达的消息
4. 您希望该应用能够跨处理架构(即多代码/多 CPU 系统)很好地扩展
5. 可扩展性是关键的设计要求(例如，以更快的速度发送更多消息)
6. 对线程故障/长时间操作的恢复能力是可取的

根据我的经验，最有效的线程架构是使用线程池。所有消息都到达一个队列，多个线程在队列上等待并在消息到达时对其进行处理。线程池实现可以对您拥有的所有三个线程分布示例进行建模。

#1 单线程处理所有消息 => 只有一个线程的线程池

#2 Thread per N message types => 具有 N 个线程的线程池，每个线程查看队列以找到合适的消息类型

#3 所有消息的多线程=>多线程线程池

这种设计的好处是您可以根据处理环境或消息负载按比例缩放线程中的线程数。线程数量甚至可以在运行时扩展，以适应正在经历的实时消息负载。

有许多适用于大多数平台的优秀线程池库，包括 .NET、C++/STL、Java 等。

关于你的第二个问题，是否使用标准的windows消息发送机制。这种机制带来了巨大的开销，实际上仅用于通过 Windows 应用程序的 UI 循环发送消息。除非这是您要解决的问题，否则我建议不要将其用作一般的消息调度解决方案。此外，Windows 消息携带的数据非常少——它不是基于对象的模型。每个 Windows 消息都有一个代码和一个 32 位参数。这可能不足以建立一个干净的消息传递模型。最后，Windows 消息队列不是为处理队列饱和、线程饥饿或消息重新排队等情况而设计的；这些是在实现合适的消息队列解决方案时经常出现的情况。