进程间通信方式

在 *** 作系统中，一个进程可以理解为是关于计算机资源集合的一次运行活动，其就是一个正在执行的程序的实例。从概念上蚂州来说，一个进程拥有它自己的虚拟CPU和虚拟地址空间，任何一个进程对于彼此而言都是相互独立的，这也引入了一个问题 —— 如何让进程之间互相通信？

由于进程之间是互相独立的，没有任何手段直接通信，因此我们需要借助 *** 作系统来辅助它们。举个通俗的例子，假如A与B之间是独立的，不能彼此联系，如果它们想要通信的话可以借助第三方C，比如A将信息交给C，C再将信息转交给B —— 这就是进程间通信的主要思想 —— 共享资源。

这里要解决的一个重要的问题就是如何避免竞争，即避免多个进程同时访问临界区的资源。

共享内存是进程间通信中最简单的方式之一。共享内存允许两个或更多进程访问同一块内存。当一个进程改变了这块地址中的内容的时候，其它进程都会察觉到这个更改。

你可能会想到，我直接创建一个文件，然后进程不就都可以访问了？

是的，但这个方法有几个缺陷：

Linux下采用共享内存的方式来使进程完成对共享资源的访问，它将磁盘文件复制到内存，并创建虚拟地址到该内存的映射，就好像该资源本来就在进程空间之中，此后我们就可以像 *** 作本地变量一样去 *** 作它们了，实际的写入磁盘将由系统选择最佳方式完成，例如 *** 作系统可能会批量处理加排序，从而液帆大大提高IO速度。

如同上图一样，进程将共享内存映射到自己的虚拟地址空间中，进程访问共享进程就好像在访问自己的虚拟内存一样，速度是非常快的。

共享内存的模型应该是比较好理解的：在物理内存中创建一个共享资源文件，进程将该共享内存绑定到自己的虚拟内存之中。

这里要解决的一个问题是如何将同一块共享内存绑定到自己的虚拟内存中，要知道在不同进程中使用 malloc 函数是会顺序分配空闲内存，而不会分配同一块内存，那么要如何去解决这个问题呢？

Linux *** 作系统已经想办法帮我们解决了这个问题，在 #include <sys/ipc.h>和 #include <sys/shm.h>头文件下，有如下几个shm系列函数：

通过上述几个函数，每个独立的进程只要有统一的共享内存标识符便可以建立起虚拟地址到物理地址的映射，每个虚拟地址将被翻译成指向共享区域的物理地址，这样就实现了对共享内存的访问。

还有一种相像的实现是采用mmap函数，mmap通常是直接对磁盘的映射——因此不算是共享内存，存储量非常大，但访问慢； shmat与此相反，通常将资源保存在内存中创建映射，访问快，但存储量较小。

不过要注意一点， *** 作系统并不保证任何并发问题，例如两个进程同时更改同一块内存区域，正如你和你的朋友在线编辑同一个文档中的同一个标题，这会导致一些不好的结果，所以我们需要借助信号量或其他方式来完成同步。

信号量是迪杰斯特拉最先提出的一种为解决 同步不同执行线程问题 的一种方法，进程与线程抽象来看大同小异，所以 信号量同样可以用于同步进程间通信 。

信号量 s 是具有非负整数值的全局变量，由两种特殊的 原子 *** 作 来实现，这两种原子 *** 作称为 P 和 V ：

信号量并不用来传送资源，而是用来保护共享资源，理解这一点是很重要的，信号量 s 的表示的含义为 同时允许最大访问资源的进程数量 ，它是一个全局变量。来考虑一个上面简单的例子：两个进程同时修改而造成错误，我们不考虑读者而仅仅考虑写者进程，在这个例子中共享资源最多允许一个进程修改资源，因此我们初始化 s 为1。

开始时，A率先写入资源，此时A调用P(s)，将 s 减一，此时 s = 0，A进入共享区工作。

此时，进程B也想进入共享区修改资源，它调用P(s)发现此时s为0，于是挂起进程，加入等待队列。

A工闹物雹作完毕，调用V(s)，它发现s为0并检测到等待队列不为空，于是它随机唤醒一个等待进程，并将s加1，这里唤醒了B。

B被唤醒，继续执行P *** 作，此时s不为0，B成功执行将s置为0并进入工作区。

此时C想要进入工作区......

可以发现，在无论何时只有一个进程能够访问共享资源，这就是信号量做的事情，他控制进入共享区的最大进程数量，这取决于初始化s的值。此后，在进入共享区之前调用P *** 作，出共享区后调用V *** 作，这就是信号量的思想。

在Linux下并没有直接的P&V函数，而是需要我们根据这几个基本的sem函数族进行封装：

正如其名，管道就如同生活中的一根管道，一端输送，而另一端接收，双方不需要知道对方，只需要知道管道就好了。

管道是一种最 基本的进程间通信机制。 管道由pipe函数来创建： 调用pipe函数，会在内核中开辟出一块缓冲区用来进行进程间通信，这块缓冲区称为管道，它有一个读端和一个写端。管道被分为匿名管道和有名管道。

匿名管道通过pipe函数创建，这个函数接收一个长度为2的Int数组，并返回1或0表示成功或者失败：

int pipe(int fd[2])

这个函数打开两个文件描述符，一个读端文件，一个写端，分别存入fd[0]和fd[1]中，然后可以作为参数调用 write 和 read 函数进行写入或读取，注意fd[0]只能读取文件，而fd[1]只能用于写入文件。

你可能有个疑问，这要怎么实现通信？其他进程又不知道这个管道，因为进程是独立的，其他进程看不到某一个进程进行了什么 *** 作。

是的，‘其他’进程确实是不知道，但是它的子进程却可以！这里涉及到fork派生进程的相关知识，一个进程派生一个子进程，那么子进程将会复制父进程的内存空间信息，注意这里是复制而不是共享，这意味着父子进程仍然是独立的，但是在这一时刻，它们所有的信息又是相等的。因此子进程也知道该全局管道，并且也拥有两个文件描述符与管道挂钩，所以 匿名管道只能在具有亲缘关系的进程间通信。

还要注意，匿名管道内部采用环形队列实现，只能由写端到读端，由于设计技术问题，管道被设计为半双工的，一方要写入则必须关闭读描述符，一方要读出则必须关闭写入描述符。因此我们说 管道的消息只能单向传递。

注意管道是堵塞的，如何堵塞将依赖于读写进程是否关闭文件描述符。如果读管道，如果读到空时，假设此时写端口还没有被完全关闭，那么 *** 作系统会假设还有数据要读，此时读进程将会被堵塞，直到有新数据或写端口被关闭；如果管道为空，且写端口也被关闭，此时 *** 作系统会认为已经没有东西可读，会直接退出，并关闭管道。

对于写一个已经满了的管道同理而言。

管道内部由内核管理，在半双工的条件下，保证数据不会出现并发问题。

了解了匿名管道之后，有名管道便很好理解了。在匿名管道的介绍中，我们说其他进程不知道管道和文件描述符的存在，所以匿名管道只适用于具有亲缘关系的进程，而命名管道则很好的解决了这个问题 —— 现在管道有一个唯一的名称了，任何进程都可以访问这个管道。

注意， *** 作系统将管道看作一个抽象的文件，但管道并不是普通的文件，管道存在于内核空间中而不放置在磁盘(有名管道文件系统上有一个标识符，没有数据块)，访问速度更快，但存储量较小，管道是临时的，是随进程的，当进程销毁，所有端口自动关闭，此时管道也是不存在的， *** 作系统将所有IO抽象的看作文件，例如网络也是一种文件，这意味着我们可以采用任何文件方法 *** 作管道，理解这种抽象是很重要的，命名管道就利用了这种抽象。

Linux下，采用mkfifo函数创建，可以传入要指定的‘文件名’，然后其他进程就可以调用open方法打开这个特殊的文件，并进行write和read *** 作(那肯定是字节流对吧)。

注意，命名管道适用于任何进程，除了这一点不同外，其余大多数都与匿名管道相同。

消息队列亦称报文队列，也叫做信箱，是Linux的一种通信机制，这种通信机制传递的数据会被拆分为一个一个独立的数据块，也叫做消息体，消息体中可以定义类型与数据，克服了无格式承载字节流的缺陷(现在收到void*后可以知道其原本的格式惹):

同管道类似，它有一个不足就是每个消息的最大长度是有上限的，整个消息队列也是长度限制的。

内核为每个IPC对象维护了一个数据结构struct ipc_perm，该数据结构中有指向链表头与链表尾部的指针，保证每一次插入取出都是O(1)的时间复杂度。

一个进程可以发送信号给另一个进程，一个信号就是一条消息，可以用于通知一个进程组发送了某种类型的事件，该进程组中的进程可以采取处理程序处理事件。

Linux下 unistd.h 头文件下定义了如图中的常量，当你在shell命令行键入 ctrl + c 时，内核就会前台进程组的每一个进程发送 SIGINT 信号，中止进程。

我们可以看到上述只有30个信号，因此 *** 作系统会为每一个进程维护一个int类型变量sig，利用其中30位代表是否有对应信号事件，每一个进程还有一个int类型变量block，与sig对应，其30位表示是否堵塞对应信号(不调用处理程序)。如果存在多个相同的信号同时到来，多余信号会被存储在一个等待队列中等待。

我们要理解进程组是什么，每个进程属于一个进程组，可以有多个进程属于同一个组。每个进程拥有一个进程ID，称为 pid ，而每个进程组拥有一个进程组ID，称为 pgid ，默认情况下，一个进程与其子进程属于同一进程组。

软件方面(诸如检测键盘输入是硬件方面)可以利用kill函数发送信号，kill函数接受两个参数，进程ID和信号类型，它将该信号类型发送到对应进程，如果该pid为0，那么会发送到属于自身进程组的所有进程。

接收方可以采用signal函数给对应事件添加处理程序，一旦事件发生，如果未被堵塞，则调用该处理程序。

Linux下有一套完善的函数用以处理信号机制。

Socket套接字是用与网络中不同主机的通信方式，多用于客户端与服务器之间，在Linux下也有一系列C语言函数，诸如socket、connect、bind、listen与accept，我们无需花太多时间研究这些函数，因为我们可能一辈子都不会与他们打交道，对于原理的学习，后续我会对Java中的套接字socket源码进行剖析。

对于工作而言，我们可能一辈子都用不上这些 *** 作，但作为对于 *** 作系统的学习，认识到进程间是如何通信还是很有必要的。

面试的时候对于这些方法我们不需要掌握到很深的程度，但我们必须要讲的来有什么通信方式，这些方式都有什么特点，适用于什么条件，大致是如何 *** 作的，能说出这些，基本足以让面试官对你十分满意了。

　1.源程序的编译

在Linux下面,如果要编译一个C语言源程序,我们要使用GNU的gcc编译器. 下面

我们以一个实例来说明如何使用gcc编译器.

假设我们有下面一个非常简单的源程序(hello.c):

int main(int argc,char **argv)

{

printf("Hello Linux\n")

}

要编译这个程序,我们只要在命令行下执行:

gcc -o hello hello.c

gcc 编译器就会为我们生成一个hello的可执行文件.执行./hello就可以中袭看到程

序的输出结果了.命令行中 gcc表示我们是用gcc来编译我们的源程序,-o 选项表示

我们要求编译器给我们输出的可执行文件名为hello 而hello.c是我们的源程序文件.

gcc编译器有许多选项,一般来说我们只要知道其中的几个就够了. -o选项我们

已经知道了,表示我们要求输出的可执行文件名. -c选项表示我们只要求编译器输出

目标代码,而不必要输出可执行文件. -g选项表示我们要求编译器在编译的时候提

供我们以后对程序进行调试的信息.

知道了这三个选项,我们就可以编译我们自己所写的简单的源程序了,如果你

想要知道更多的选项,可以查看gcc的帮助文档,那里有着许多对其它选项的详细说

明.

2.Makefile的编写

假设我们有下面这样的一个程序,源代码如下:

#include "mytool1.h"

#include "mytool2.h"

int main(int argc,char **argv)

{

mytool1_print("hello")

mytool2_print("hello")

}

#ifndef _MYTOOL_1_H

#define _MYTOOL_1_H

void mytool1_print(char *print_str)

#endif

#include "mytool1.h"

void mytool1_print(char *print_str)

{

printf("This is mytool1 print %s\n",print_str)

}

#ifndef _MYTOOL_2_H

#define _MYTOOL_2_H

void mytool2_print(char *print_str)

如唤#endif

　卖橡兄　#include "mytool2.h"

void mytool2_print(char *print_str)

{

printf("This is mytool2 print %s\n",print_str)

}

当然由于这个程序是很短的我们可以这样来编译

gcc -c main.c

gcc -c mytool1.c

gcc -c mytool2.c

gcc -o main main.o mytool1.o mytool2.o

这样的话我们也可以产生main程序,而且也不时很麻烦.但是如果我们考虑一

下如果有一天我们修改了其中的一个文件(比如说mytool1.c)那么我们难道还要重

新输入上面的命令?也许你会说,这个很容易解决啊,我写一个SHELL脚本,让她帮我

去完成不就可以了.是的对于这个程序来说,是可以起到作用的.但是当我们把事情

想的更复杂一点,如果我们的程序有几百个源程序的时候,难道也要编译器重新一

个一个的去编译?

为此,聪明的程序员们想出了一个很好的工具来做这件事情,这就是make.我们

只要执行以下make,就可以把上面的问题解决掉.在我们执行make之前,我们要先

编写一个非常重要的文件.--Makefile.对于上面的那个程序来说,可能的一个

Makefile的文件是:

# 这是上面那个程序的Makefile文件

main:main.o mytool1.o mytool2.o

gcc -o main main.o mytool1.o mytool2.o

main.o:main.c mytool1.h mytool2.h

gcc -c main.c

mytool1.o:mytool1.c mytool1.h

gcc -c mytool1.c

mytool2.o:mytool2.c mytool2.h

gcc -c mytool2.c

有了这个Makefile文件,不过我们什么时候修改了源程序当中的什么文件,我们

只要执行make命令,我们的编译器都只会去编译和我们修改的文件有关的文件,其

它的文件她连理都不想去理的.

下面我们学习Makefile是如何编写的.

在Makefile中也#开始的行都是注释行.Makefile中最重要的是描述文件的依赖

关系的说明.一般的格式是:

target: components

TAB rule

第一行表示的是依赖关系.第二行是规则.

比如说我们上面的那个Makefile文件的第二行

main:main.o mytool1.o mytool2.o

表示我们的目标(target)main的依赖对象(components)是main.o mytool1.o

mytool2.o 当倚赖的对象在目标修改后修改的话,就要去执行规则一行所指定的命

令.就象我们的上面那个Makefile第三行所说的一样要执行 gcc -o main main.o

mytool1.o mytool2.o 注意规则一行中的TAB表示那里是一个TAB键

Makefile有三个非常有用的变量.分别是$@,$^,$<代表的意义分别是:

$@--目标文件,$^--所有的依赖文件,$<--第一个依赖文件.

如果我们使用上面三个变量,那么我们可以简化我们的Makefile文件为:

# 这是简化后的Makefile

main:main.o mytool1.o mytool2.o

gcc -o $@ $^

main.o:main.c mytool1.h mytool2.h

gcc -c $<

mytool1.o:mytool1.c mytool1.h

gcc -c $<

mytool2.o:mytool2.c mytool2.h

gcc -c $<

经过简化后我们的Makefile是简单了一点,不过人们有时候还想简单一点.这里

我们学习一个Makefile的缺省规则

.c.o:

gcc -c $<

这个规则表示所有的 .o文件都是依赖与相应的.c文件的.例如mytool.o依赖于

mytool.c这样Makefile还可以变为:

# 这是再一次简化后的Makefile

main:main.o mytool1.o mytool2.o

gcc -o $@ $^

.c.o:

gcc -c $<

好了,我们的Makefile 也差不多了,如果想知道更多的关于Makefile规则可以查

看相应的文档.

3.程序库的链接

试着编译下面这个程序

#include

int main(int argc,char **argv)

{

double value

printf("Value:%f\n",value)

}

这个程序相当简单,但是当我们用 gcc -o temp temp.c 编译时会出现下面所示

的错误.

/tmp/cc33Kydu.o: In function `main':

/tmp/cc33Kydu.o(.text+0xe): undefined reference to `log'

collect2: ld returned 1 exit status

出现这个错误是因为编译器找不到log的具体实现.虽然我们包括了正确的头

文件,但是我们在编译的时候还是要连接确定的库.在Linux下,为了使用数学函数,我

们必须和数学库连接,为此我们要加入 -lm 选项. gcc -o temp temp.c -lm这样才能够

正确的编译.也许有人要问,前面我们用printf函数的时候怎么没有连接库呢?是这样

的,对于一些常用的函数的实现,gcc编译器会自动去连接一些常用库,这样我们就没

有必要自己去指定了. 有时候我们在编译程序的时候还要指定库的路径,这个时候

我们要用到编译器的 -L选项指定路径.比如说我们有一个库在 /home/hoyt/mylib下

,这样我们编译的时候还要加上 -L/home/hoyt/mylib.对于一些标准库来说,我们没

有必要指出路径.只要它们在起缺省库的路径下就可以了.系统的缺省库的路径/lib

/usr/lib /usr/local/lib 在这三个路径下面的库,我们可以不指定路径.

还有一个问题,有时候我们使用了某个函数,但是我们不知道库的名字,这个时

候怎么办呢?很抱歉,对于这个问题我也不知道答案,我只有一个傻办法.首先,我到

标准库路径下面去找看看有没有和我用的函数相关的库,我就这样找到了线程

(thread)函数的库文件(libpthread.a). 当然,如果找不到,只有一个笨方法.比如我要找

sin这个函数所在的库. 就只好用 nm -o /lib/*.so|grep sin>~/sin 命令,然后看~/sin

文件,到那里面去找了. 在sin文件当中,我会找到这样的一行libm-2.1.2.so:00009fa0

W sin 这样我就知道了sin在 libm-2.1.2.so库里面,我用 -lm选项就可以了(去掉前面

的lib和后面的版本标志,就剩下m了所以是 -lm).

4.程序的调试

我们编写的程序不太可能一次性就会成功的,在我们的程序当中,会出现许许

多多我们想不到的错误,这个时候我们就要对我们的程序进行调试了.

最常用的调试软件是gdb.如果你想在图形界面下调试程序,那么你现在可以选

择xxgdb.记得要在编译的时候加入 -g选项.关于gdb的使用可以看gdb的帮助文件.由

于我没有用过这个软件,所以我也不能够说出如何使用. 不过我不喜欢用gdb.跟踪

一个程序是很烦的事情,我一般用在程序当中输出中间变量的值来调试程序的.当

然你可以选择自己的办法,没有必要去学别人的.现在有了许多IDE环境,里面已经自

己带了调试器了.你可以选择几个试一试找出自己喜欢的一个用.

5.头文件和系统求助

有时候我们只知道一个函数的大概形式,不记得确切的表达式,或者是不记得函数在那个头文件进行了说明.这个时候我们可以求助系统，比如说我们想知道fread这个函数的确切形式,我们只要执行 man fread 系统就会输出着函数的详细解释的.和这个函数所在的头文件说明了。如果我们要write这个函数说明，当我们执行man write时，输出的结果却不是我们所需要的。因为我们要的是write这个函数的说明，可是出来的却是write这个命令的说明。为了得到write的函数说明我们要用man 2 write。2表示我们用的是write这个函数是系统调用函数，还有一个我们常用的是3表示函数是c的库函数。

三种类型的XSI IPC：消息队列，信号量，和共享内存，有许多共同点。这里将讨论这些共同的特性，后面会依次讨论它们的各自的特性。

XSI的IPC函数基于System V的IPC函数。这三种类型的IPC起源于1970s的一个被称作"Columbus UNIX"的内部AT&T的UNIX版本。后来这三种悄御类型的IPC被添加到System V中。它们不使用文件系统的命名空间而是使用自己的标准的命名空间。

我们应当知道（前面的表格中也说了）：消息队列，信号量和共享内存被定义为Single UNIX Specification的XSI扩展。

内核中的每个IPC的结构(消息队列，信号量或者共享内存段)，通过一个非负的整数来引用。例如当发送或者从一个消息队列中接收消息的时候，我们所知道的就只是这个队列的标识。和文件描述符号不同，IPC的标识不是一个小的整数。实际上，当创建并且移走一个IPC结构的时候，相应的标识符号会连续地增加，知道它到达一个最大的正整数值，然后又回归到0。

标识只是一个IPC对象的内部名字。协作进程需要一个外部名字策略以便能够使用IPC对象进行交互。为了实现这个目的，IPC对象和一个关键字进行关联，这个关键字的作用就像是一个外部的名字一样。

当创建一个IPC结构的时候（通过调用msgget, semget, 或 shmget），必须指定一个关键字。关键字的类型是key_t，它是在头文件<sys/types.h>中被定义的一个长整数类型。这个关键字在内核里面被转换成一个标识。

对于一个客户和服务，有许多种不同的方法来使用同一个IPC结构。

返回：如果成功返回关键字，如果失败返回(key_t)-1。

这里的path参数必须引用一个已经存在的文件名称，而参数id则只使用它的低8位来生成关键字。

ftok创建的关键字，一般是通过path对应的文件的stat结构的st_dev和st_ino成员结合project ID，来进行生成的。如果指定两个不同的path，那么ftok通常会返回两个不同的关键字。然而由于i-node成员和关键字都是通过长整型来存储的，所以在创建关键字的时候必然会丢失一些信息（关于索引节点的唯一性的信息），这意味着如果两个不同的路径名，如果指定的project id是相同的话，也是有可能会产生同样值的关键字的。

三个get函数（msgget,semget和shmget）都有两个类似的参数：一个关键字和一个整数标记。

当一个 新的IPC结构被创建 （通常是服务进程创建）的时候，通常是由如下情况导致：

如果想要引用一个已经存在的队列（通常是客户进程引用），关键字必须要和创建该队列时候的关键字一样并且没有指定IPC_CREAT标记。

需要注意的是，我们不可能通过IPC_PRIVATE关键字来引用一个已经存在的queue，因为这个特殊的关键字值会创建一个新的queue。为引用一个已经存在的使用关键字IPC_PRIVATE创建的queue，我们必须知道相应的表示，然后在其他的IPC调用中（例如msgsnd和msgrcv）使用那个标识，而不是通过get函数来获得标识。

如果我们想要创建一个新的IPC结构变银胡量，那么我们需要确保我们不会引用一个使用同样表示的已经存在的IPC结构变量，我们必须同时设定IPC_CREAT和IPC_EXCL位的标记。使用这个方法，当已经存在了那个IPC结构的时候，会导致返回一个EEXIST错误（这个情况就类启搏岩似使用指定了O_CREAT和O_EXCL标记的open函数）。

XSI的IPC结构和一个ipc_perm结构相关联，这个结构定义了权限和属主，并且至少包含了如下的成员：

每种实现都包含了额外的成员，可以通过查看你系统上面的<sys/ipc.h>文件来了解完整的定义。

当建立IPC的时候，所有的成员都会被初始化。之后，我们可以通过调用msgctl,semctl,或者shmctl来修改uid,gid,和mode成员。为了能够改变这些值，调用进程必须是IPC结构的创建者或者是超级用户。修改这些成员和给一个文件调用chown或者chmod类似。

mode成员的值和<sys/stat.h>中定义的文件访问权限很类似，但是对于任何的IPC结构没有相应的执行权限。同时，消息队列和共享内存使用read和write但是信号量使用read和alter。下表展示的就是每种IPC形式的六个权限：

有一些实现定义了一些常量来表示这些权限，但是这些都没有被Single UNIX Specification标准化。

我们可以看到，所有三种形式的XSI IPC都有内部的限制。所有这些限制可以通过内核来进行配置，我们后面讲到每一种IPC的时候，将会对这些限制进行描述。

每个平台提供了它自己的显示和修改特定限制的方法。FreeBSD 5.2.1,Linux 2.4.22,和Mac OS X 10.3提供了sysctl命令来查看和修改内核配置参数。Solaris 9可以通过修改文件/etc/system然后重新启动来修改内核的配置参数。

在Linux上面，呢可以通过运行"ipcs -l"来查看IPC相关的限制。在FreeBSD上，相应的命令是"ipcs -T"。在Solaris上，你可以运行sysdef -i来查看可以调节的参数。

(内容不会被及时释放)XSI IPC的一个基本问题就是IPC结构是系统范围内的，没有一个引用计数。例如，如果我们创建了一个消息队列，将一些消息放到这个队列上面，然后终止进程，那么消息队列和它的内容并不会被删除。它们会保留在系统中，直到其它进程调用msgrcv或者msgctl进行特定的读取或删除，或者通过执行ipcrm命令，或者通过系统的重新启动。与pipe相比，pipe会在最后一个引用它的进程结束的时候完全地被移除。对于FIFO，尽管管道的名字在文件系统中保留着（以管道文件的形式），但是FIFO中保留的任何数据会在最后一个引用该FIFO的进程结束的时候被移走。

(无法像文件那样直观)另外一个XSI IPC的问题就是，这些IPC结构不是通过在文件系统中的名字被知道的。我们无法通过前面的函数来访问和修改它们。有许多系统调用(msgget,semop,shmat,等等)被添加到内核中以便支持这些IPC对象。我们无法通过ls命令来查看IPC对象，我们无法通过rm命令来删除它们，我们也无法通过chmod命令来修改它们的权限。然而，有两个命令"ipcs"和"ipcrm"被加入了进来，可以实现类似的功能。

(无法进行高级的文件 *** 作)因为这些IPC不能使用文件描述符号，所以我们不能构对它们使用多I/O函数(select和poll函数)进行 *** 作。这使得我们同时使用多个IPC结构或者通过文件或者设备I/O使用任何这些IPC结构变得非常的困难。例如，我们无法有一个服务进程不经过忙等待的循环方式等待消息被放到两个消息队列中的一个上面。

还有更多关于有点和缺点的讨论或者争辩，这里就不一一列举了。同时有一个描述各种IPC特性的表格，这里也不列出了。具体参见参考资料。

后面将会对三种IPC分别进行详细的讲解。

参考： APUE2/ch15lev1sec6.html

---