第9章 LINUX内核注释.docVIP

第9章System Ⅴ IPC Unix从开发的早期就提供了管道的机制，管道在同一机器的两个进程间的双向通信方面工作的相当出色。后来，BSD（Berkeley Software Development）的Unix版本又提供了通用的套接字socket，它用来在不同机器的两个进程之间进行通信（或者是同一机器的）。 Unix System V版本增加了被视为一体的三个机制，现在它们被统称为System V IPC。像管道一样，这些机制都可以用于同一机器上的进程间通信，不过与管道和套接字不同的是，System V的IPC特性使得同一机器上的许多进程之间都可以互相通信，而不是仅限于两个进程。而且，管道——不是套接字——还有一个更大的限制就是两个通信中的进程必须相关。它们必须有一个建立管道的共同祖先进程——通常情况下，一个进程是另一个的父进程，或者这两个都是为它们建立管道的父进程的子进程。System V IPC像套接字一样使得进程间通信（IPC）不需要有共同的继承关系，只需要一个经过协商的的协议。 组成System V IPC的三个进程间通信机制是：消息队列、信号量和共享内存。 消息队列 System V的消息队列（message queues）是进程之间互相发送消息的一种异步（asynchronously）方式，在这种情形之下，发送方不必等待接收方检查它的消息——即在发送完消息后，发送方就可以从事其它工作了——而接收方也不必一直等待消息。对消息进行编码和解码是发送者和接受者进程的工作；消息队列的执行并不会给它们特别的帮助。这就形成了一个实现起来相对比较简单的通用机制，尽管是以增加应用程序的复杂度为代价来获得这种简明性的。 这里是一个可能发生在SMP机器上的简单的应用情景。运行在一个CPU上的调度程序把工作请求发送到一个特定的消息队列上。工作请求可能以各种形式出现：用来破译代码的一组密码、需要进行计算的在不规则图形里的象素范围、在一个原子系统里要更新的一部分空间，或者诸如此类的任务。与此同时，工作者进程在其它CPU上运行，只要它们空闲就从消息队列中检索消息，然后再把结果消息发送到另一个消息队列上去。 这种体系结构很容易实现，而且假定选择好了每个消息中被请求工作的粒度，就能极大的提高机器中CPU的利用效率。（还要注意的是，因为调度进程可能不用做许多工作，所以调度进程的CPU上大部分时间也可以运行一个工作者进程。）以这种方式，消息队列可以被用作是远程过程调用（RPC）的一种低级形式。 新消息总是加在队列的末尾，不过它们并不总是从排头移出；你将能够在本章中看到，消息可以从队列的任何地方被移出。在某个方面，消息队列与语音邮件类似：新消息总是在末尾，不过消息接收方可以从列表的中间接收（以及删除）消息。 消息队列概述 首先对消息队列进行介绍是因为它的实现最简单，不过它仍然体现出了几个所有三种System V IPC机制都具有的共同结构特征。 给进程提供了四种与队列相关的系统调用： msgget——一个不合时宜的名字：读者可能认为这会得到一个等待的消息。但实际它不会。调用者提供一个消息队列键标（key），如果存在一个队列，msgget就用该键标为它返回一个标识号，如果没有队列，就用它为一个新的消息队列返回一个标识号。因此，msgget所得到的不是一个消息，而是唯一标识一个消息队列的标识号。 msgsnd——向一个消息队列发送一条消息。 msgrcv——从一个消息队列中接受一条消息。 msgctl——在消息队列上执行一组管理操作——检索关于它的限制的信息（比如队列所允许的最大消息数据量）、删除一个队列，等等。 Struct msg 15919：struct msg代表在队列中等待的一个消息。它有如下成员： msg_next——指向队列中的下一个消息——当然假如这是最后一个消息就为NULL。 msg_type——用户指定类型编码；它的使用在本章讨论消息如何被接收时再进行分析。 msg_spot——指向消息内容的开头。读者后面将看到，为消息分配的空间总是紧靠在struct msg的上边，因此msg_spot恰恰指向struct msg末尾之后的位置。 msg_stime——记录消息被发送的时间。因为消息以先进先出（FIFO）顺序保存，所以队列中的消息拥有的msg_stime值就是单调非递减的。 msg_ts——记录消息的大小容量（“ts”是“text size”的缩写，尽管消息不一定非要是人们可以读懂的文本）。一条消息的最大容量是MSGMAX，它在15902行定义为4056字节。推测一下，这应该是4K（4096字节）减去一个struct msg的结果。不过b只有20字节，因此还有另外的20字节有待说明。 Struct msqid_ds 15865：msqi