Unix&Linux下的管道通信机制及管道通信程序示例

Unix/Linux下的管道通信机制及测试程序示例一．基础知识

1.1管道

1.1.1 基本知识

在Linux中，管道是一种使用非常频繁的通信机制。从本质上说，管道也是一种文件，如用于普通文件的打开（OPEN）、读（READ）、写（WRITE）、关闭（CLOSE）等系统调用同样可以作用于管道。但它又和一般的文件有所不同，管道可以克服使用文件进行通信的两个问题，具体表现为：

· 限制管道的大小。实际上，管道是一个固定大小的缓冲区。在Linux中，该缓冲区的大小为1页，即4K字节，使得它的大小不像文件那样不加检验地增长。使用单个固定缓冲区也会带来问题，比如在写管道时可能变满，当这种情况发生时，随后对管道的write()调用将默认地被阻塞，等待某些数据被读取，以便腾出足够的空间供write()调用写。

· 读取进程也可能工作得比写进程快。当所有当前进程数据已被读取时，管道变空。当这种情况发生时，一个随后的read()调用将默认地被阻塞，等待某些数据被写入，这解决了read()调用返回文件结束的问题。

注意：从管道读数据是一次性操作，数据一旦被读，它就从管道中被抛弃，释放空间以便写更多的数据。

因此，管道具有其他方式所不能具有的特点：

（1）发送进程能以比较简单的方式，源源不断地把产生的消息以自然流的方式写入管道，而不需要考虑对每次传送的信息长度的限制。

（2）接收进程能在适当的时机从管道按需提取信息，同样也不必以固定的消息长度为单位进行。

（3）发送和接收进程都能以一定的方式了解对方进程是否存在，并且可以通过管道的现存消息情况（管道空、管道有信息、管道满）等相互协调动作。

1.1.2 分类

管道包括三种:1)普通管道PIPE，通常有种限制，一是半双工，只能单向传输；二是只能在父子进程间使用。2)流管道s_pipe: 去除了第一种限制，可以

双向传输。3)命名管道:name_pipe，又称FIFO，去除了第二种限制，可以在许多并不相关的进程之间进行通讯。

1.1.3 区别

（1）管道（Pipe）：管道可用于具有亲缘关系进程间的通信，允许一个进程和另一个与它有共同祖先的进程之间进行通信。

（2）命名管道（named pipe）：命名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。命名管道在文件系统中有对应的文件名。命名管道通过命令mkfifo或系统调用mkfifo来创建。

1.2UNIX/LINUX支持的管道通信模式

1.2.1发展起源

linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的。而对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD（加州大学伯克利分校的伯克利软件发布中心）在进程间通信方面的侧重点有所不同。前者对Unix早期的进程间通信手段进行了系统的改进和扩充，形成了“system V IPC”，通信进程局限在单个计算机内；后者则跳过了该限制，形成了基于套接口（socket）的进程间通信机制。

Linux则把两者继承了下来。如下图：

其中，最初Unix IPC包括：管道、FIFO、信号；

System V IPC包括：System V消息队列、System V信号灯、System V共享内存区；

Posix IPC包括： Posix消息队列、Posix信号灯、Posix共享内存区。1.2.2 管道通信模式

（1）管道（Pipe）：管道可用于具有亲缘关系进程间的通信，允许一个进程和另

一个与它有共同祖先的进程之间进行通信。

（2）命名管道（named pipe）：又称FIFO，命名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。命名管道在文件系统中有对应的文件名。命名管道通过命令mkfifo或系统调用mkfifo来创建。

1.3 资料

https://www.360docs.net/doc/c87941171.html,/linshui91/archive/2010/09/29/1838770.html

https://www.360docs.net/doc/c87941171.html,/shinehoo/article/details/5818843

https://www.360docs.net/doc/c87941171.html,/guopengzhang/article/details/5528260

https://www.360docs.net/doc/c87941171.html,/a2010/0103/999/000000999870.shtml

二．实验过程

2.1 创建名为lab61.c的文件，并编码

/*****************lab61.c********************/

#include

#include

#include

#include

int main(){

//define the pipe input port and output port

int port[2]; //port[0]:output port, as know read port; port[1]:input port, as know write port

//define the pipe

char putinpipe[100]; //putinpipe: store the buffer data into pipe

char getfrompipe[100];//getfrompipe: get the data from pipe and store in the buffer

//create the pipe

pipe(port);

//define the pid_t

pid_t id1, id2;

id1 = fork();

if (id1>0){//come in the parent process, id1=childID

id2= fork();

if(id2>0){//come in the parent process

wait(0);

read(port[0], getfrompipe, 50);

printf("%s\n", getfrompipe);

wait(0);

read(port[0], getfrompipe, 50);

printf("%s\n", getfrompipe);

exit(0);

} else if (id2==0){//come in the child2 process

lockf(port[1],1,0);

sprintf(putinpipe,"child 2 process is sending message!");

write(port[1], putinpipe, 50);

sleep(5);

lockf(port[1],0,0);

exit(0);

}

} else if(id1==0) {//come in the child1 process

lockf(port[1],1,0);

sprintf(putinpipe,"child 1 process is sending message!");

write(port[1], putinpipe, 50);

sleep(5);

lockf(port[1],0,0);

exit(0);

}

return 0;

}

2.1.1 系统调用管道（普通管道）

2.1.2 创建子进程

2.2 编译并运行

#gcc –o lab61.out lab61.c

#./lab61.out

其中为了避免偶偶然，多次运行程序发现结果均一致。

2.3 分析

在试验中，为了避免偶然，多次运行程序，发现结果跟2.2中的一致；同时，设

置sleep()时长或者删掉sleep()，发现结果跟2.2中也一样。这说明，程序先

运行了P1，后运行了P2.

2.4 问题

2.4.1 sleep(5)起什么作用

原因：sleep（5）的作用是保证程序将管道中的所有数据读取完之后再解锁，以防止在读取完之前管道的数据被改写而造成不一致的错误。

在 2.3中将两个sleep（5）删掉再实验，发现很快就显示结果而且结果和删“sleep”之前一样，这是因为实验机器的配置高，性能好，执行速度快，如果在一台配置稍低的机子上实验，则会发生错误现象,进而引起程序的崩溃。

2.4.2子进程1和2为什么也能对管道进行操作

原因：

(1)Unix/Linux系统中，使用系统调用fork来创建进程，但是创建进程的过程是两步，并不是windows中的一步。这两步为: ①调用fork，父子进程用户相同的存储映像、同样的环境字符串以及打开文件。②子进程执行execve或一个类似的系统调用，以修改其存储映像并运行一个新的程序，这一目的主要是让子进程处理其文件描述符，使之完成对标准输入、标准输出和标准出错的重定向。其中，有些文件描述符是不能被修改的，如打开的文件等。（来自《现代操作系统》）

(2) 利用pipe( )建立起来的无名文件,只有该系统调用所返回的文件描述符来标识该文件。当这些进程不再使用此管道时，核心收回其索引结点。

(3)由于fork()在创建进程的第一步中，父子进程拥有相同的存储映像、同样的环境字符串以及打开文件，故子进程知道父进程用pipe()创建的管道的文件描述符。而且，文件描述符中的一些数据时共享的，是子进程所不能修改，管道的信息就是其中不能被修改的。

因此，基于以上原因，父子进程均知道管道的文件描述符，故能进行正常的通信。