消息机制
消息处理的编程思路是当某件事产生后只发送一条事件产生消息以通知相应执行机构执行的一种编程思路。
消息定义
什么是消息，消息是一个指示，可以是数字，字符串，字符或者是任何形式的其他标识符
消息定义的形式与消息检读的方式相对应，通常我们可以将其定义为一些常量，常量可以是各种类型，甚至可以是是复合类型。
#define MSG_KEY1DOWN 1
#define MAG_CMD0 "OPEN"
#define MSG_STATE_OVER 'V'
消息处理
定义消息处理的方式并不难，难在如何检读消息、处理消息
因为在一个并行任务程序中，通常会有很多消息处理的任务，因此消息也绝对不只一个，如何把那些相关的或不相关的消息分门别类地处理好，还真不是一个容易的事情。不过不容易不可怕，可怕的是没有好的魔法。现在我们来修炼消息处理的魔法在小规模的消息处理中，可以使用不同的变量来收/发不同类型的消息。
案例代码
问题分析
3.10.2节所示的消息处理机制分类简单，代码易懂，但是重复代码多，这种做法只适合那种消息种类少的应用场合，如果消息种类很多，那么在消息检读时将会出现很多switch语句，这显然不合理，这时就需要另一种消息收发检读策略–消息队列。
在小规模的消息处理中，由于不同类型的消息由不同的变量来指示，所以不同的消息可能会使用相同的编码，如消息 MSG TASKI RUN与消息 MSG TASK2 RUN 的编码都是 1.由于它们使用的是不同的编码空间，所以可以使用相同的编码而不会产生消息检读错乱。
在大规模的消息处理中，由于我们将简化代码，不希望出现众多的检读switch，所以不能出现很多的编码空间。理想的编码空间只能有一个，所有消息不分类型，统一编码，在一个统一的检读器中检读。
这种策略需要一个足够长度的队列，以保存随机产生而来不及处理的消息。所有的消息产生都先发送到队列，然后在检读时从队列中按照先入先出的原则来检读并处理它们。
消息队列
回顾思考
在 3.10.4节中，有着稍微复杂一些的队列处理机制，这似乎为我们的工作额外增加了一些麻烦，但事实上，使用了这种机制之后，在使用上会无比简单。一旦我们向系统发送了一个消息，我们甚至不用担心消息发到了哪里，由谁来响应消息，我们所要做的，就只是把消息发送出去。消息被发送出去后就进入消息队列排队等候它的主人。排队的消息遵循先进先出的原则，来不及被主人认领的消息将在队列中等候，直到轮到它出队并被主人领走。不同的消息通常会有不同的主人，它们的主人会一直盯着消息队列最前面出队的消息。一旦消息从队列头出来，就会马上被主人响应。消息被响应后就会被遗弃，并把处理机会留给队列中的其他成员。
