一、system V版本的进程间通信技术  

        通过之前的学习，我们大致可以感受出来，共享内存，消息队列和信号量在使用的时候是有很多共性的。它们三个的接口，包括接口中传的参数有的都有很大的相似度。其实，共享内存，消息队列和信号量是操作系统针对本地进程间通信特意设计出来的system V版本的进程间通信（IPC,Inter Process Communication）技术。共享内存，消息队列和信号量所管理的资源称为IPC资源。在操作系统底层，共享内存，消息队列和信号量都是有相对应的结构体将它们维护起来的。

二、共享内存，消息队列和信号量对应的结构体

2.1、共享内存内核结构体

• shm_perm：表示该共享内存的所有权和权限 

下面就是ipc_perm结构体的内核 

• _key：就是我们用ftok函数设置进共享内存中的key。
• uid：共享内存所有者的有效用户ID。这通常是在创建共享内存段时指定用户的ID。只有具有适当权限的用户才能对共享内存段执行特定的操作（如读、写或删除）。
• gid：共享内存所有者所属组的有效组ID。类似于uid，它用于确定组级别的权限。如果一个进程属于拥有共享内存段的组，那么它可能具有额外的访问权限。
• cuid：共享内存创建者的有效用户ID。这个字段用于记录最初创建共享内存段的用户的ID，通常用于审计或追踪目的。
• cgid：共享内存创建者所属组的有效组ID。类似于cuid，它记录了创建共享内存段的组的ID。
• mode：该共享内存的权限
• _seq：_seq字段通常用于确保IPC对象的唯一性和追踪对象的更改。当IPC对象（如共享内存段、信号量或消息队列）被创建、修改或删除时，其序列号可能会发生变化。这有助于防止IPC对象的重复创建和避免竞态条件

        只有超级用户或创建IPC对象的进程才有权改变ipc_perm结构体的值。其他进程只能根据这些值来确定它们对共享内存段的访问权限。 

共享内存内核结构体剩余成员变量

• shm_segsz：该共享内存的大小。
• shm_atime：该共享内存最后一次挂接的时间。
• shm_dtime：该共享内存最后一次去挂接的时间。
• shm_ctime：该共享内存最后一次修改的时间。
• shm_cpid：创建该共享内存的进程的pid。
• shm_lpid：   最后一个挂接或去挂接该共享内存的进程的pid。
• shm_nattch：表示当前附加到共享内存段的进程数。 

2.2、消息队列内核结构体

 2.3、信号量内核结构体

 

2.4、内核间的共性

        上面详细地介绍了共享内存的内核结构及其各个字段代表的含义，消息队列和信号量的字段有的含义跟共享内存是一样的，如果大家想了解的更多，可以在命令行中通过man指令进行查阅，这里不做赘述。这里只是想输出一个结论，共享内存、消息队列和信号量的内核在实现的时候是有很多相似性的，换句话说，就是它们三个是一个体系中的东西，在本地进程间通信这个体系中。 

三、共享内存，消息队列和信号量在内核中的组织方式

        通过上面的介绍，我们会发现，描述共享内存，消息队列和信号量的结构体的第一个成员变量都是一个叫struct ipc_perm的结构体，这个结构体在阐述共享内存时已经有详细介绍了。其中，在操作系统内核中，会有一个ipc_id_ary数组，类型就为struct ipc_perm*。未来当我们要创建一个共享内存或消息队列或信号量时，我们需要先顺着ipc_id_array数组中的下标往后找，找到一个下标后在这个下标中填入新的初始化好的struct ipc_perm*（有对应的算法来往后推算数组下标），再将共享内存或消息队列或信号量的结构体中其它的属性填好，这样一个共享内存或消息队列或信号量就被创建出来了。当我们要删除一个IPC资源的时候，只需要在该数组中将对应下标中的struct ipc_perm*释放掉就可以了。这样对IPC资源的管理就变成了对数组的增删查改。

        当我们要对一个IPC资源做管理时，只需要对ipc_id_array数组中对应位置的struct ipc_perm*做强转就可以将这个结构体地址强转成一个共享内存或消息队列或信号量的地址，这时该IPC资源的类型就确定了，类型确定了里面该有的属性也就确定了。这就是C++语言中多态的思想。因为操作系统是C语言写的，所以只能用指针强转实现上面的效果。

        因为结构体的第一个成员变量是struct ipc_perm*，我们也知道结构体第一个成员变量的地址就是整个结构体的起始地址，未来通过第一个成员变量的地址加上偏移量我们也可以访问该结构体中的其他成员变量。

四、总结

        其实System V的通信技术在现在已经逐渐被边缘化了。System V是一个单独设计的内核模块，其标准的设计不符合Linux下一切皆文件的思想。尽管隶属于文件部分，但已经是一个独立的模块，且shmid与文件描述符之间的兼容性做得并不好。通过上面的学习我们也可以看到，System V自己搞了一个类似于文件描述符表的ipc_id_ary数组，与文件那一套背离了。网络通信使用的是文件的接口，这使得System V标准在整合进网络结构时面临困难。随着POSIX标准的出现和普及，它为进程间通信提供了一套统一的接口和规范，使得不同的操作系统和应用程序在进程间通信上有了更好的兼容性和互操作性。这也进一步削弱了System V IPC的地位。System V版本的进程间通信技术由于设计上的局限性、与现代操作系统和网络结构的不兼容性以及新兴技术的出现，逐渐被边缘化。