IPC之SystemV弊端--共享内存、信号量和消息队列共三种

svipc - System V interprocess communication mechanisms

linux实现的System V interprocess communication (IPC)机制包含消息队列（message queues），信号集（semaphore sets），和共享内存（shared memory segments)。

man 7 svipc

SystemV消息通信弊端

在新的应用中很少会用到System V IPC，因为它已经被POSIX IPC取代了。但编写老程序时仍可能用到。

像管道一样，IPC存在于内核（实际上是内核内存）而不是像FIFO一样存在于文件系统中。IPC的集中结构有时合起来叫做IPC对象（其实是信号灯、消息队列和共享内存）。

 每个对象都通过它的标识符来引用和访问，标识符是一个正整数，它唯一地标识出对象本身和它的类型。每个标识符的类型都是唯一的，但同一标识符的值可以用于一个消息队列、一个信号灯和一个共享内存区。标识符称为该结构上所有其他操作的句柄。IPC结构标识符不想文件描述符那样使用较小的正整数。实际上，随着结构的创建和删除，标识符的值（正式的名称叫做槽使用顺序号）会不断增加直至达到一个最大值为止，然后再转回到0并重新开始。在linux系统中，标识符声明为整数，所以它的值最大可能为65535。

     每个IPC结构都有get函数创建，在创建了一个IPC结构之后，使用同一个关键字（key）的get函数的后续调用不会创建新结构，但返回和现在结构相关的标识符。这可以让两个或两个以上的进程用同一关键字key调用get函数以建立一条IPC通道。

    接下来的问题是怎样确保所有要使用同一IPC结构的进程都使用相同的关键字。一种方法为，实际创建结构的进程给get函数传递IPC_PRIVATE关键字，这能保证创建一个新结构。然后创建IPC结构的进程把返回的标识符保存在其他进程能够访问的文件系统中。在父进程fork或exec一个子进程的场合，父进程可以把返回的标识符作为一个参数传递给创建子进程的函数exec。

     另一种传递关键字的方法是把它保存在公共的头文件中，这样一来所有包含了这个头文件的程序都能够访问到相同的关键字。这种方法引出的一个问题，没有进程直到它是正在创建一个新结构呢还是只访问已经由其他进程创建好的结构。这种方法带来的另外一个问题是关键字可能已经被另外一个无关的程序使用了。结果使用这个关键字的进程必须包含处理这种可能性的代码。

     第三种方法是用ftok函数，这个函数接受一个路径名和一个称为项目标识符的单个字符作为参数，返回一个关键字可以传递给get函数。有程序员保证所有的进程实现直到路径名和项目标识符。你可以使用前面提到过的方法之一：在公共的头文件中包含路径名和项目标识符，或者把他们保存在预定义的配置文件中。

    不幸的是，ftok有个严重的缺陷：它不能保证产生唯一的关键字，这一来出现了和前面讨论的第二种方法一样的问题。在下列情况下，ftok生成唯一的关键字：

>>当两个不同的符号链接到同一文件上。

>>当路径名的索引节点的前16个比特位具有相同的值。

>>当系统带有两个相同次设备号的硬盘时，在系统由多个磁盘控制器的情况下才会出现。主设备号不相同，但次设备号可以相同。