进程间通信之XSI IPC

XSI IPC源自于系统V的IPC功能。

有三种IPC我们称作XSI IPC,即消息队列、信号量以及共享存储器,它们之间有很多相似之处。

1、标识符和键

每个内核中的IPC结构(消息队列、信号量或共享存储段)都用一个非负整数的标识符(identifier)加以引用。例如,为了对一个消息队列发送或取消息,只需要知道其队列标识符。与文件描述符不同,IPC标识符不是小的整数。当一个IPC结构被创建,以后又被删除时,与这种结构相关的标识符连续加1,直到达到一个整型数的最大正值,然后又回转到0.

标识符是IPC对象的内部名。为使多个合作进程能够在同一IPC对象上会合,需要提供一个外部名方案。为此使用了键(key),每个IPC对象都与一个键相关联,于是键就用作为该对象的外部名

无论何时创建IPC结构(调用msgget、semget或shmget),都应指定一个键,键的数据类型是基本系统数据类型key_t,通常在头文件<sys/types.h>中被定义为长整型。键由内核变换成标识符

有多种方法使客户进程和服务器进程在同一IPC结构上会合:

(1)服务器进程可以指定键IPC_PRIVATE创建一个新IPC结构,将返回的标识符存放在某处(例如一个文件)以便客户进程取用。键IPC_PRIVATE保证服务器进程创建一个新IPC结构。这种技术的缺点是:服务器进程要将整型标识符写到文件中,此后客户进程又要读文件取得此标识符。

IPC_PRIVATE键也可以用于父、子进程关系。父进程指定IPC_PRIVATE创建一个新IPC结构,所返回的标识符在调用fork后可由子进程使用。接着,子进程又可将此标识符作为exec函数的一个参数传给一个新程序。

(2)在一个公用头文件中定义一个客户进程和服务器进程都认可的键。然后服务器进程指定此键创建一个新的IPC结构。这种方法的问题是该键可能已与一个IPC结构相结合,在此情况下,get函数(msgget、semget或shmget)出错返回。服务器进程必须处理这一错误,删除已存在的IPC结构,然后试着再创建它。

(3客户进程和服务器进程认同一个路径名和项目ID(项目ID是0-255之间的字符值),接着调用函数ftok将这两个值变换为一个键然后在方法(2)中使用此键。ftok提供的唯一服务就是由一个路径名和项目ID产生一个键。

#include <sys/ipc.h>
key_t ftok(const char *path, int id);
返回值:若成功则返回键,若出错则返回(key_t)-1

path参数必须引用一个现存文件。当产生键时,只是用id参数的低8位。

ftok创建的键通常是下列方式构成的:按给定的路径名取得其stat结构(http://www.cnblogs.com/nufangrensheng/p/3501385.html),从该结构中取出部分st_dev和st_ino字段,然后再与项目ID组合起来。如果两个路径名引用两个不同的文件,那么,对这两个路径名调用ftok通常返回不同的键。但是,因为i节点号和键通常都存放在长整型中,于是创建键时可能会丢失信息(?)。这意味着,如果使用同一项目ID,那么对于不同文件的两个路径名可能产生相同的键

三个get函数(msgget、semget和shmget)都有两个类似的参数:一个key和一个整型flag。如若满足下列两个条件之一,则创建一个新的IPC结构(通常由服务器进程创建):

  • key是IPC_PRIVATE;
  • key当前未与特定类型的IPC结构相结合,并且flag中指定了IPC_CREAT位。

为访问现存的队列(通常由客户进程进行),key必须等于创建该队列时所指定的键,并且不应指定IPC_CREAT。

注意,为了访问一个现存队列,决不能指定IPC_PRIVATE作为键。因为这是一个特殊的键值,它总是用于创建一个新队列。为了访问一个用IPC_PRIVATE键创建的现存队列,一定要知道与该队列相结合的标识符,然后在其他IPC调用中(例如msgsnd和msgrvc)使用该标识符。

如果希望创建一个新的IPC结构,而且要确保不是引用具有同一标识符的一个现行IPC结构,那么必须在flag中同时指定IPC_CREAT和IPC_EXCL位。这样做了以后,如果IPC结构已经存在就会造成出错,返回EEXIST(这与指定了O_CREAT和O_EXCL标志的open相类似)。

2、权限结构

XSI IPC为每一个IPC结构设置了一个ipc_perm结构。该结构规定了权限和所有者。它至少包括下列成员:

struct ipc_perm {
    uid_t    uid;     /* owner's effective user id */
    gid_t    gid;     /* owner's effective group id */
    uid_t    cuid;    /* creator's effective user id */
    gid_t    cgid;    /* creator's effective group id */
    mode_t   mode;    /* access modes */
    ...
};

每种实现在其ipc_perm结构中会包括另外一些成员。如欲了解你所用系统中它的完整定义,请参见<sys/ipc.h>。

在创建IPC结构时,对所有字段都赋初值。以后,可以调用msgctl、semctl或shmctl修改uid、gid和mode字段。为了改变这些值,调用进程必须是IPC结构的创建者或超级用户。更改这些字段类似于对文件调用chown和chmod。

mode字段的值类似于http://www.cnblogs.com/nufangrensheng/p/3502097.html中表4-5所示的值,但是对于任何IPC结构都不存在执行权限。另外,消息队列和共享存储使用术语读(read)和写(write),而信号量则使用术语读(read)和更改(alter)。表15-2中对每种IPC说明了6种权限。

20130911104759093

某些实现定义了表示每种权限的符号常量,但是这些常量并不包括在Single UNIX Specification中。

3、结构限制

三种形式的XSI IPC都有内置限制(built-in limit)。这些限制的大多数可以通过重新配置内核而加以更改。

在报告和修改限制方面,每种平台都提供它自己的方法。FreeBSD 5.2.1、Linux 2.4.22和Mac OS X 10.3提供了sysctl命令,用该命令观察和修改内核配置参数。Solaris9修改内核配置参数的方法是,修改文件/etc/system,然后重新启动。

在Linux中,你可以运行 ipcs -l以显示IPC相关的限制。

未命名

4、优点和缺点

XSI IPC的主要问题是:IPC结构是在系统范围内起作用的,没有访问计数。例如,如果进程创建了一个消息队列,在该队列中放入了几条消息,然后终止,但是消息队列及其内容并不会被删除。它们余留在系统中直至出现下述情况:由某个进程调用msgrcv或msgctl读消息或删除消息队列;或某个进程执行ipcrm(1)命令删除消息队列;或由正在再启动的系统删除消息队列。将此与管道相比,当最后一个访问管道的进程终止时,管道就被完全地删除了。对于FIFO而言,虽然当最后一个引用FIFO的进程终止时其名字仍保留在系统中,直至显示地删除它,但是留在FIFO中的数据却在此时全部被删除,于是也就徒有其名了。

XSI IPC的另一个问题是:这些IPC结构在文件系统中没有名字。我们不能用文件I/O和文件和目录章节中所述的函数来访问它们或修改它们的特性。为了支持它们不得不增加了十几条全新的系统调用(msgget、semop、shmat等)。我们不能用ls命令见到IPC对象,不能用rm命令删除它们,也不能用chmod命令更改它们的访问权限。于是,就不得不增加新的命令ipcs(1)和ipcrm(1)。

因为这些IPC不使用文件描述符,所以不能对它们使用多路转接I/O函数:select和poll。这就使得难于一次使用多个IPC结构,以及在文件或设备I/O中使用IPC结构。

表15-3对不同形式IPC的某些特征进行了比较。

                                         表15-3 不同形式IPC之间的特征比较

未命名

表15-3中的“无连接”指的是无需先调用某种形式的打开函数就能发送消息的能力。正如前述,因为需要有某种技术以获得队列标识符,所以我们并不认为消息队列具有无连接特性。因为所有这些形式的IPC都限制在单主机上,所以它们都是可靠的。当消息通过网络传送时,丢失消息的可能性就要加以考虑。“流控制”指的是:如果系统资源(缓冲区)短缺或者如果接收进程不能再接收更多消息,则发送进程就要休眠。当流控制条件消失时,发送进程应自动被唤醒。

表15-3中没有表示的一个特征是:IPC设施能否自动地为每个客户进程创建一个到服务器进程的唯一连接。STREAMS以及UNIX流套接字可以提供这种能力。

本篇博文内容摘自《UNIX环境高级编程》(第二版),仅作个人学习记录所用。关于本书可参考:http://www.apuebook.com/

posted @ 2014-02-23 10:40  ITtecman  阅读(2456)  评论(0编辑  收藏  举报