基于消息分发的多线程程序设计，常见的问题，以及解决方法

商业软件的开发，大部分都需要有一些为其它模块提供服务的底层模块。这些底层模块由于实现的是一些通用功能，需要同时为几个高层模块提供功能，因此通常被设计成一种基于消息队列的框架。任何需要访问这些通用功能的高层模块，都可以通过发送消息并接受返回值来得到需要的服务。

这种构架的设计，一般是围绕消息队列来展开的：首先有一个消息队列，并对外暴露发送消息的API；然后实现一个负责维护并调度该消息队列的线程，该线程负责维护消息队列，并分发消息；最后是一系列处理特定消息的功能模块。消息由暴露给外层模块的API发送到消息队列，由调度线程接受消息，并分发给消息处理模块，然后由处理模块对不同消息进行处理，将处理结果返回给高层模块，这就是一个完善的基于消息队列的公用模块。为了实现这种模块的可扩展性，消息处理模块一般采取一种基于注册的设计，允许用户注册特定消息的消息处理函数。

这种构架从结构上看，是非常完善的，模块功能也比较好划分，因此应用广泛。但是根据个人经验，大部分这种模块的实现，在细节上都会有一些细微的瑕疵，给后期代码的维护和扩展带来麻烦，一下是个人遇到过的3中情况。

1. 消息的定义没有做到“原子化”。单一的功能被认为拆分成好几个消息。比如在一个为其它模块提供数据库访问服务的模块，将打开记录集，获取记录集，关闭记录集分成了3个消息，由于这3个消息在逻辑上有着顺序关系，而消息处理并不能很好的保证这种顺序关系，从而导致获取记录集时，记录集已经被关闭等等类似情况的出现（由于记录集可能很大，需要分多次获取，这种设计有时候也是不可避免）。

要处理这种情况，唯一的办法是保证想办法保证消息处理的顺序性，比如使