消息队列可不可以这样用：
应用程序与守护进程通讯，需要数据传输，定义两条消息队列，SendMsg()用来向守护进程发送数据， ReceiveMsg()用来从守护进程接受数据，也就是多个进程同时与同一个进程通讯，在测试时会有time out，不常见，现在我不确定是守护进程在运算数据是耗费的时间太长，还是因为我对消息队列的理解不对，所以用的不对？
之所以不敢确定是守护进程的问题是因为守护进程要与另外一台计算机通讯，但是测试环境的网络不太稳定，我的观点是有两种可能造成time out：1守护进程与另一台计算机的通讯时间太长，ReceiveMsg()超时；2消息队列的使用不对。我倾向与1。

你的用法没问题，事实上我的系统也采用了这种通讯方式，但要注意的是消息队列的接受方式需要按你的实际情况考虑，BLOCK或UNBLOCK。

yuanyawei(漂风)所说的BLOCK或UNBLOCK不是互斥, 你可能理解错了,消息队列mq本身就能保证消息send、receive的原子操作，为什么还要另加互斥信号量？

偶觉得，消息队列是一种效率很高的进程间通讯；消息队列太多会降低系统的效率；向这样的服务器/客户之间的通讯，应该尽量少用消息队列。
最好的做法是这样（偶认为）：服务器建立两个消息队列；一个用于控制，一个用于数据；客户启动时需要向服务器申请一个消息ID（通过控制队列），在以后的通讯中，用此ID同服务器通讯（服务器通过ID辨别客户）。
按上方法，控制队列是需要同步的；而数据传输队列不用同步（用不同的ID实现multiplexing）。

消息队列其实是没有时间"time out”的，除非你自己去实现一个，他只取决你读的当时队列中是否有消息，没有就返回，如果你的交易业务处理需要一段时间，那send后马上recv可能都会出错返回。 我没有写测试程序，你自己可以试一下。
另外，像你说的A,B两者业务的情况，用一个也可能会有问题，你还是仔细考虑一下吧。

用你的客户端程序的PID不就行了