Linux进程间通信分类（非原创）

风雪夜归人_95 2016-03-01

展开全文

本文主要摘自网络：http://blog.csdn.net/sunmenggmail/article/details/7888746
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）由于Unix版本的多样性，电子电气工程协会（IEEE）开发了一个独立的Unix标准，这个新的ANSI Unix标准被称为计算机环境的可移植性操作系统界面（PSOIX）。现有大部分Unix和流行版本都是遵循POSIX标准的，而Linux从一开始就遵循POSIX标准；2）BSD并不是没有涉足单机内的进程间通信（socket本身就可以用于单机内的进程间通信）。事实上，很多Unix版本的单机 IPC留有BSD的痕迹，如4.4BSD支持的匿名内存映射、4.3+BSD对可靠信号语义的实现等等。

linux下进程间通信的几种主要手段简介：

管道（Pipe）及有名管道（named pipe）：管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；
信号（Signal）：信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又能够统一对外接口，用sigaction函数重新实现了signal函数）；
报文（Message）队列（消息队列）：消息队列是消息的链接表，包括Posix消息队列system V消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。
共享内存：使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。
信号量（semaphore）：主要作为进程间以及同一进程不同线程之间的同步手段。
套接口（Socket）：更为一般的进程间通信机制，可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的，但现在一般可以移植到其它类Unix系统上：Linux和System V的变种都支持套接字。

1、管道（pipe）

管道是进程间通信的主要手段之一。一个管道实际上就是个只存在于内存中的文件，对这个文件的操作要通过两个已经打开文件进行，它们分别代表管道的两端。管道是一种特殊的文件，它不属于某一种文件系统，而是一种独立的文件系统，有其自己的数据结构。根据管道的适用范围将其分为：无名管道和命名管道。

● 无名管道

主要用于父进程与子进程之间，或者两个兄弟进程之间。在linux系统中可以通过系统调用建立起一个单向的通信管道，且这种关系只能由父进程来建立。因此，每个管道都是单向的，当需要双向通信时就需要建立起两个管道。管道两端的进程均将该管道看做一个文件，一个进程负责往管道中写内容，而另一个从管道中读取。这种传输遵循“先入先出”（FIFO）的规则。

● 命名管道

命名管道是为了解决无名管道只能用于近亲进程之间通信的缺陷而设计的。命名管道是建立在实际的磁盘介质或文件系统（而不是只存在于内存中）上有自己名字的文件，任何进程可以在任何时间通过文件名或路径名与该文件建立联系。为了实现命名管道，引入了一种新的文件类型——FIFO文件（遵循先进先出的原则）。实现一个命名管道实际上就是实现一个FIFO文件。命名管道一旦建立，之后它的读、写以及关闭操作都与普通管道完全相同。虽然FIFO文件的 inode节点在磁盘上，但是仅是一个节点而已，文件的数据还是存在于内存缓冲页面中，和普通管道相同。

2、环形缓冲区

每个管道只有一个页面作为缓冲区，该页面是按照环形缓冲区的方式来使用的。这种访问方式是典型的“生产者——消费者”模型。当“生产者”进程有大量的数据需要写时，而且每当写满一个页面就需要进行睡眠等待，等待“消费者”从管道中读走一些数据，为其腾出一些空间。相应的，如果管道中没有可读数据， “消费者”进程就要睡眠等待。

2.1环形缓冲区实现原理

环形缓冲区是嵌入式系统中一个常用的重要数据结构。一般采用数组形式进行存储，即在内存中申请一块连续的线性空间，可以在初始化的时候把存储空间一次性分配好。只是要模拟环形，必须在逻辑上把数组的头尾相连接。只要对数组最后一个元素进行特殊的处理——访问尾部元素的下一元素时，重新回到头部元素。对于从尾部回到头部只需模缓冲长度即可（假设maxlen为环形缓冲的长度，当读指针read指向尾部元素时，只需执行read=read%maxlen 即可使read回到头部元素）。

2.2读写操作

环形缓冲区要维护写端（write）和读端（read）两个索引。写入数据时，必须先确保缓冲区没有满，然后才能将数据写入，最后将write指针指向下一个元素；读取数据时，首先要确保缓冲区不为空，然后返回read指针对应得元素，最后使read指向下一个元素的位置。读写操作伪代码：

2.3判断“满”和“空”

当read和write指向同一个位置时环形缓冲区为空或满。为了区别环满和空，当read和write重叠的时候环空；而当write比read快，追到距离read还有一个元素间隔的时候，就认为环已经满了。环形缓冲区原理图如图3所示。

3 并发访问

考虑到在不同环境下，任务可能对环形缓冲区的访问情况不同，需要对并发访问的情况进行分析。

在单任务环境下，只存在一个读任务和一个写任务，只要保证写任务可以顺利的完成将数据写入，而读任务可以及时的将数据读出即可。如果有竞争发生，可能会出现如下情况：

Case1：假如写任务在“写指针加1，指向下一个可写空位置”执行完成时被打断，如图3所示，此时写指针write指向非法位置。当系统调度读任务执行时，如果读任务需要读多个数据，那么不但应该读出的数据被读出，而且当读指针被调整为0是，会将以前已经读出的数据重复读出。

Case2：假设读任务进行读操作，在“读指针加1”执行完时被打断，如图4所示，此时read所处的位置是非法的。当系统调度写任务执行时，如果写任务要写多个数据，那么当写指针指到尾部时，本来缓冲区应该为满状态，不能再写，但是由于读指针处于非法位置，在读任务执行前，写任务会任务缓冲区为空，继续进行写操作，将覆盖还没有来的及读出的数据。