线程模型的具体选择应该由您要解决的问题的性质决定。为这样的应用程序设计线程模型不一定有一种“正确”的方法。但是,如果我们采用以下假设:
- 消息频繁到达
- 消息是独立的,不会过分依赖共享资源
- 希望尽快响应到达的消息
- 您希望应用程序能够跨处理架构(即多代码/多 CPU 系统)很好地扩展
- 可扩展性是关键的设计要求(例如,更多消息以更快的速度)
- 对线程故障/长时间操作的弹性是可取的
根据我的经验,最有效的线程架构是使用线程池。所有消息都到达一个队列,多个线程在队列上等待并在消息到达时处理它们。线程池实现可以对您拥有的所有三个线程分布示例进行建模。
#1 单线程处理所有消息 => 只有一个线程的线程池
#2 每 N 个消息类型的线程 => 具有 N 个线程的线程池,每个线程查看队列以找到合适的消息类型
#3 所有消息的多个线程 => 具有多个线程的线程池
这种设计的好处是您可以根据处理环境或消息负载成比例地缩放线程中的线程数。线程的数量甚至可以在运行时扩展,以适应正在经历的实时消息负载。
大多数平台都有很多不错的线程池库可用,包括 .NET、C++/STL、Java 等。
至于你的第二个问题,是否使用标准的windows消息调度机制。这种机制会带来很大的开销,并且实际上仅用于通过 Windows 应用程序的 UI 循环来泵送消息。除非这是您要解决的问题,否则我建议不要将其用作一般的消息发送解决方案。此外,Windows 消息携带的数据非常少——它不是基于对象的模型。每个 Windows 消息都有一个代码和一个 32 位参数。这可能不足以建立一个干净的消息传递模型。最后,windows 消息队列不是为处理队列饱和、线程不足或消息重新排队等情况而设计的;这些是在实施一个体面的消息队列解决方案时经常出现的情况。