XSI IPC 简介

2015-05-12 00:31:32   最后更新: 2015-05-12 00:31:59   访问数量:1149




有三种 IPC 被称为“XSI IPC”:

  1. 消息队列
  2. 信号量
  3. 共享内存

 

他们之间有很多相似之处

 

每个内核中的 IPC 结构(消息队列、信号量、共享内存)都用一个非负整数的标识符加以引用

与文件描述符不同,IPC 标识符不是小的整数,当一个 IPC 结构被创建,与该结构相关的标识符连续加 1,直到达到整型最大数值,然后再从 0 开始加

 

由于标识符的数字难以使用和记忆,因此标识符仅被作为 IPC 对象的内部名,而“键”则是 IPC 对象的外部名供程序使用,键是 key_t 类型的数据,定义于 sys/type.h 中,通常为长整型

外部调用使用键,由内核转化为标识符

 

但是,当客户进程与服务端进程通信的过程中,怎么保证“键”与标识符及 IPC 结构在服务端进程与客户进程之间会合呢?

主要有下列方法:

  1. 服务器进程可以指定键 IPC_PRIVATE 创建一个新的 IPC 结构(键 IPC_PRIVATE 保证服务器进程创建的 IPC 结构是一个新的结构),将返回的标识符存放在某处(如一个文件中),供客户进程取用,但是,这样做需要服务端进程不断的写文件,而客户进程又需要不断的读文件,效率不高。当然 IPC_PRIVATE 键也可以用在父子进程通信的场景中,父进程通过 IPC_PRIVATE 键创建 IPC 结构,然后调用 fork 后子进程依然可以使用先前的标识符,只需通过 exec 将该标识符传给新的程序即可
  2. 在一个公用头文件中创建一个服务端程序和客户程序都认可的键,然后服务端进程使用指定的键创建新的 IPC 结构
  3. 客户进程和服务端进程认同同一个路径名和项目ID,接着调用函数 ftok 将两个值变换成一个键,然后如方法2中所述由服务进程创建新的 IPC 结构

 

上面所说的第三种方法中用到了一个函数 -- ftok,用来生成一个键

key_t ftok(const char *path, int id);

 

定义于 sys/ipc.h 中

调用成功返回键,否则返回 -1

 

这个函数通过从 path 指向的文件中取出 stat 结构(因此 path 所标识的文件必须是已经存在的),通过该结构中的部分 st_dev 和 st_info 字段与项目 ID 组合生成键

 

XSI IPC 为每一个 IPC 结构设置了一个 ipc_perm 结构,该结构规定了权限和所有者

struct ipc_perm { uid_t uid; // owner's effective user id gid_t gid; // owner's effective group id uid_t cuid; // creator's effective user id gid_t cgid; // creator's effective group id mode_t mode; // access modes ... ... }

 

 

各个系统对 ipc_perm 结构的实现方式不同,但是上述字段是必备的成员

该结构定义在 sys/ipc.h 中

 

可以通过调用 msgctl、semctl 活 shmctl 修改 uid、gid 和 mode 字段,但是调用者必须是 IPC 结构的创建者或超级用户

 

mode 取值

XSI IPC 的权限设定和 chmod 和 chown 函数的 mode 参数非常类似

XSI IPC 权限
权限mode
用户读0400
用户写(更改)0200
组读0040
组写(更改)0020
其他读0004
其他写0002

 

  • 注:上表中使用了两组术语,是因为消息队列和共享存储使用“读”和“写”,而信号量使用“读”和“更改”(alter)

 

缺点

  1. IPC 结构是在系统范围内起作用的,没有访问技术,一旦创建病放入数据,除非取出否则数据会一直遗留在系统中,即便进程终止
  2. 这些 IPC 结构不使用文件描述符,因此,不得不增加了十几条全新的系统调用来支持他们,同样,我们不能使用所有操作文件系统的已有调用,也就不能使用多路转接 IO 来一次使用多个 IPC 结构
  3. 无法实现忙-等待循环,也就不能使一个服务端程序同时等待两个消息队列
  4. 客户进程必须以某种方式获得服务进程队列的标识符,而这个标识符是一个动态值,必须每次都去读取,然后再执行 msgget 调用

 

优点

  1. 可靠
  2. 流是受控的
  3. 面向记录
  4. 可以用非先进先出的方式处理数据

 

各种 IPC 的比较

各种 IPC 的比较
IPC 类型无连接可靠流控制记录消息类型或优先级
消息队列
STREAMS
域流套接字
域数据报套接字
FIFO

 

  • 上表中的流控制指的是:如果系统资源(缓冲区)短缺或接收进程不能继续接收数据,则发送进程休眠,当接收进程可以继续接收,则发送进程自动被唤醒

 






读书笔记      技术帖      龙潭书斋      套接字      apue      unix环境高级编程      进程间通信      ipc      fifo      消息队列      message queue      消息      队列      xsi      queue      message      信号量      域套接字      ftok      ipc_perm      权限     


京ICP备15018585号