进一步解释：消息和任务

       getmsg是我举的一个简单例子。其实，显示中真正用的也基本上类似getmsg这样的调用，该调用是操作系统提供的一个核心接口调用，该函数调用目的，是在任务自身的消息队列中读取一个消息(该消息队列是操作系统实现消息通讯机制而为任务涉及的一个系统资源队列，我们可以不关心队列的内部实现，而只需要知道该队列是存放其它任务发送过来的消息即可)，读取的消息放在该函数输入的一个接受消息体对象地址空间上，如果消息队列中没有消息，那么该getmsg的系统调用就发生阻塞(这里我默认这个getmsg调用时阻塞模式，当然很多操作系统都提供非阻塞模式的参数调用方式)，直到有消息触发为止。对于该模块代码的编程人员来说，可以只关心该模块的运行流畅，当getmsg阻塞返回时，就是有信号发生了，那么这个模块就负责处理传输过来的信号。其它的事情，交给其它模块来处理，这就可以实现模块化设计和开发。这种阻塞机制的任务，一般不会把整个CPU的时间给全部占用。除非像我前面举的那个例子一样。

       所谓阻塞，就是操作系统提供的一种IO/或者操作系统资源使用的一种机制。当有一个任务有信息需要处理时，操作系统就根据调度策略把该任务调度到运行状态，给这个任务一定的CPU执行时间来运行这个任务，当该任务没有任何消息需要处理，这个任务就被调度策略放入休眠队列，把CPU时间让给其它需要使用资源的任务。这是分时复用CPU时间的多任务操作系统原理。

       有的开发人员可能不喜欢阻塞模式，往往采用非阻塞模式的调用，那么getmsg将在读取消息时，不管队列是否有消息，都无延时的返回，而通过返回值的不同，来判断是否读取到消息。那么在非阻塞方式下，在while的循环执行体中，必须加上类似sleep这样的休眠暂停调用，否则，while循环将发生无延时的循环，那么CPU将被这个任务全部占有，系统将无法正常调度。这点需要特别注意。但是这种模式下，使用sleep等调用时，对于sleep输入的时间，需要根据不同的应用情况来设置合理的时间参数，这是一个不太容易协调的问题，需要综合考虑。而采用阻塞，就可以避免这个问题。一般阻塞模式的使用，在发生系统阻塞失败的情况，阻塞一般都会返回失败的代码供调用区别对待，所以阻塞模式使用还是比较方便。