Linux进程间通信(IPC)介绍:详细解析IPC的执行流程、状态和通信机制

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: Linux进程间通信(IPC)介绍:详细解析IPC的执行流程、状态和通信机制

Posix IPC概述

POSIX.1b 实时扩展定义了一组 IPC 机制(POSIX.1b 的开发者的其中一个目标是设计出一组能弥补 System V IPC 工具的不足之处的 IPC 机制)。这些IPC机制被称为POSIX IPC。


POSIX IPC包含以下三种类型


这三种POSIX IPC机制具体如下:
1.消息队列可以用来在进程间传递消息。与System V消息队列一样,消息边界被保留了下来,这样读者和写着就以消息为单位进行通信了。POSIX消息队列允许给每个消息赋一个优先级,这样在队列中优先级较高的消息就会排在优先级较低的消息前面
2.信号量允许多个进程同步各自的动作。 System V 信号量一样,POSIX 信号量也是一个由内核维护的整数,其值永远都不会小于 0。与 System V 信号量相比,POSIX信号量在用法上要简单一些:它们是逐个分配的(与 System V 信号量集相比),并且在单个信号量上只能使用两个操作来将信号量的值加 1 或减 1(与 semop()系统调用能原子地在一个 System V 信号量集中的多个信号量上加上或减去一个任意值相比)
3.共享内存使得多个进程能够共享同一块内存区域,与System V共享内存一样,POSIX共享内存提供了一种快速IPC,一旦进程更新了共享内存之后,所发生的变更立即对共享同一区域的其他进程可见。



IPC 对象名字

  • 必须以/打头,并且后续不能有其它/,形如/somename
  • 长度不能超过NAME_MAX

三种类型的posix IPC都必须使用POSIX IPC的名字进行标识。mq_open、sem_open和shm_open这三个函数的第一个参数就是这样的一个名字,它可能是某个文件系统中的一个真正的路径名,也可能不是.

posix.1就是这么描述posix ipc名字的:

  • 它必须复合已有路径名规则(必须最多由PATH_MAX个字节构成,包括尾部的空字节).如果它以斜杠符号开头,那么对这些函数的不通调用将访问同一个队列.
  • 如果它以斜杠符号开头,那么对这些函数的不同调用将访问同一个队列。如果它不以斜杠符号开头,那么效果取决于实现.
  • 名字中额外以斜杠符号的解释由现实定义.

SusV3规定的唯一一种用来标识POSIX IPC对象的可移植方式是使用以斜线打头后面跟着一个或者多个非斜线字符的名字,比如/myproject。Linux 和其他一些实现(如 Solaris)允许采用这种可移植的命名方式来给 IPC 对象命名.
SUSv3 并没有禁止使用形式不为/myobject 的名字,但表示这种名字的语义是由实现定义的。在一些系统上,创建 IPC 对象名字的规则是不同的。可移植的应用程序中应该将IPC对象名的生成工作放在一个根据目标裁剪过的单独的函数会在头文件中



在Linux上,POSIX共享内存和消息队列的名字的最大长度为NAME_MAX(255)个字符,而信号量的名字的最大长度要少 4 个字符,这是因为实现会在信号量名字前面加上字符串sem.



为了避免移植性问题,我们应该把posix ipc的名字的#define 放在一个便于修改的头文件之中,这样在移植操作系统的时候就需要修改这个头文件.

posix.1定义了下面三个宏

S_TYPEISMQ(buf)

S_TYPEISSEM(buf)

S_TYPEISSHM(buf)

他们单个参数是指向某个stat结构的指针,其内容由fstat、lstat或stat这三个函数填入。
如果制定的ipc对象(消息队列,信号量或者是共享内存)是作为一个独特的文件类型实现的,而且参数指向的stat结构访问这样的文件类型,那么这三个宏计算出一个非0值,否则计算出的值为0.


自定义 px_ipc_name函数

解决上述移植性问题的另一种办法是自定义一个px_ipc_name的函数,它为定位posix ipc名字而添加上正确的前缀目录.

设计示例:

#include "unpipc.h"
//若成功则返回非空指针,若出错则返回NULL.
//name参数中不能有任何斜杠符.
char *px_ipc_name(const char *name)
{
    char *dir,*dst,*slash;
 
    if((dst = malloc(PATH_MAX)) == NULL)
    {
     return  NULL;
    }
 
    if((dir = getenv("PX_IPC_NAME")) == NULL) {
#ifdef  POSIX_IPC_PREFIX
    dir = POSIX_IPC_PREFIX;
#else
    dir = "/tmp/";
#endif
    }  
    slash = (dir[strlen(dir)-1] == '/') ? "" : "/";   
    snprintf(dst,PATH_MAX,"%s%s%s",dir,slash,name);
    return(dst);
}

创建与打开IPC通道

mq_open、sem_open和shm_open这三个创建或打开一个ipc对象的函数,他们的名字为oflag的第二个参数制定怎么样打开所请求的对象。这与标准open函数的第二个参数类似.图2-3给出了可组合构成这个参数的各种常值.
前三行制定怎么样打开对象:只读、只写或读写.消息队列能以其中任何一种模式打开,信号量的打开不指定任何模式(任意信号量的操作,都需要读写访问权限),共享内存对象则不能用只写模式打开.

参数介绍

  • O_CREAT:
    O_CREAT若不存在则创建由函数第一个参数制定名字的消息队列,信号量或者共享内存区的对象,则创建一个新的消息队列、信号量或者共享内存的时候,至少需要另外一个称为mode的参数.这个参数指定权限位.

这些常值定义在<sys/stat.h>中,这个参数使用umask函数或者shell的umask命令来设置.

跟创建新的文件一样,当创建一个新的消息队列、信号量或者共享内存区对象时候,其用户id被设置为当前进程的有效用户id。信号量或共享内存区对象的组id被设置为当前进程的有效组id或者某个系统默认的id。新的消息队列对象的组id被设置为当前进程的有效组id.

  • O_EXCL:

    如果这个标志和O_CREAT一起指定,那么ipc函数只在指定名字的消息队列,信号量或者共享内存对象不存在的时候才会创建新的对象。如果这个对象已经存在,而且指定了O_CREAT|o_EXCL,那么他会返回一个EEXIST的错误
    主要问题是考虑到其他进程的存在,检查锁指定名字的消息队列、信号量或共享内存区对象的存在和创建它这两个操作必须是原子的。
  • O_NONBLOCK:
    这个标志使得一个消息队列在队列为空或队列填满的时候不再会被阻塞,我们会在mq_receive和mq_send里详细讨论这个标志
  • O_TRUNC:
    如果用只读模式打开一个已经存在的共享内存对象,那么这个标志将会使对象的长度被截断为0.

图2-5,2-6 展示了打开一个ipc的真正的逻辑流程


IPC权限

新的消息队列、有名信号量或共享内存对象是由其oflag参数中含有O_CREAT标志的mq_open、sem_open、或者shm_open函数创建的。如图2-4所注,权限位与这些IPC类型的每个对象关联,与每个unix文件相互关联。
同样又这三个函数打开一个已经存在的消息队列、信号量或共享内存对象的时候定O_CREAT或制定O_CREAT但是没有制定O_EXCL同事对象已经存在,将基于下面的消息执行权限测试:
1)创建时候赋予这个ipc对象的权限位;
2)锁请求的访问类型(O_RDONLY、O_WRONLY或这O_RDWR);
3)调用进程的有效用户ID、有效组ID以及各个辅助组ID(若支持的话).
大多数unix内核按照如下步骤进行权限测试.
1)如果当前进程的有效用户ID为0(超级用户),那就允许访问.
2)在当前进程的有效用户ID等于这个ipc对象的属主的前提下,如果相应用户的权限位已经设置,那么就允许访问,否则会拒绝访问.
比如用户以读权限访问ipc的时候,那么这个用户的读权限位必须要设置
3)在当前进程的有效组ID或它的某个辅助组id等于这个ipc对象的组的id前提下,如果响应的组访问权限已经设置,那么就允许访问,否则拒绝.
4)如果相应的其他用户访问权限位已经设置,那么允许访问,否则禁止访问
这4个步骤按照所列的步骤尝试.如果当前的进程应有ipc对象的时候,那么访问权限的授予或者拒绝只依赖与用户访问权限----组访问权限不会考虑.类似的当前进程不应有这个ipc对象,但是它属于某个组,那么访问允许或者拒绝只依赖组,其他用户访问权限绝不会考虑。


POSIX与system V IPC的区别

  • POSIX IPC
    POSIX接口更简单:使用类似于文件I/O的open、close、unlink等接口
    POSIX使用名字代替键来标识IPC对象
    对IPC对象引用计数,简化了对IPC对象的删除
    跟文件类似,删除操作也仅仅是删除了IPC对象的名字
    只有当IPC对象的引用计数变成0之后才能真正销毁
  • System V IPC
    System V IPC 可移植性好:几乎所有的UNIX系统都支持System V,POSIX在UNIX系统中只是一个可选组件,有些UNIX系统并不支持
    Linux系统一般会支持system V
    Linux2.6开始陆续支持POSIX…

  • 效率
    在信号量这种常用的同步互斥手段方面,POSIX在无竞争条件下是不会陷入内核的,而SYSTEM V则是无论何时都要陷入内核,因此性能稍差。
  • 冗余
    POSIX的sem_wait函数成功获取信号量后,进程如果意外终止,将无法释放信号量,而System V则提供了SEM_UNDO选项来解决这个问题。因此,相比而言,SystemV更加可靠。
  • 应用
    可能有小部分操作系统没有实现POSIX标准,System V更加广泛些,但是考虑到可移植性POSIX必然是一个趋势。在IPC,进程间的消息传递和同步上,似乎POSIX用得较普遍,而在共享内存方面,POSIX实现尚未完善,system V仍为主流。
  • 多线程与多进程
    在观察使用进程间通信手段后,会发现在多线程中使用的基本是POSIX标准提供的接口函数,而多进程则是基于System V

POSIX编程注意事项

使用POSIX消息队列和共享内存时,需要实时库librt链接,编译时需指定-lrt
使用POSIX信号量时,需要和线程库libthread链接起来,编译时需指定-lpthread

总结

三种posix ipc------消息队列,共享内存和信号量都是用标识符来标示的.但是这些路径名既可以是文件系统中实际的路径名字,也可以不是,这一点会导致移植性问题.
当我们用open打开ipc对象的时候,我们必须给open的对象访问权限,当打开一个已经存在的ipc对象的时候,锁执行的权限测试与打开一个已经存在的文件时候一样.


目录
相关文章
|
9天前
|
存储 编译器 Linux
动态链接的魔法:Linux下动态链接库机制探讨
本文将深入探讨Linux系统中的动态链接库机制,这其中包括但不限于全局符号介入、延迟绑定以及地址无关代码等内容。
104 16
|
22小时前
|
监控 安全 开发工具
鸿蒙HarmonyOS应用开发 | HarmonyOS Next-从应用开发到上架全流程解析
HarmonyOS Next是华为推出的最新版本鸿蒙操作系统,强调多设备协同和分布式技术,提供丰富的开发工具和API接口。本文详细解析了从应用开发到上架的全流程,包括环境搭建、应用设计与开发、多设备适配、测试调试、应用上架及推广等环节,并介绍了鸿蒙原生应用开发者激励计划,帮助开发者更好地融入鸿蒙生态。通过DevEco Studio集成开发环境和华为提供的多种支持工具,开发者可以轻松创建并发布高质量的鸿蒙应用,享受技术和市场推广的双重支持。
108 10
|
4天前
|
域名解析 弹性计算 安全
阿里云服务器租用、注册域名、备案及域名解析完整流程参考(图文教程)
对于很多初次建站的用户来说,选购云服务器和注册应及备案和域名解析步骤必须了解的,目前轻量云服务器2核2G68元一年,2核4G4M服务器298元一年,域名注册方面,阿里云推出域名1元购买活动,新用户注册com和cn域名2年首年仅需0元,xyz和top等域名首年仅需1元。对于建站的用户来说,购买完云服务器并注册好域名之后,下一步还需要操作备案和域名绑定。本文为大家展示阿里云服务器的购买流程,域名注册、绑定以及备案的完整流程,全文以图文教程形式为大家展示具体细节及注意事项,以供新手用户参考。
|
21天前
|
缓存 监控 Java
Java线程池提交任务流程底层源码与源码解析
【11月更文挑战第30天】嘿,各位技术爱好者们,今天咱们来聊聊Java线程池提交任务的底层源码与源码解析。作为一个资深的Java开发者,我相信你一定对线程池并不陌生。线程池作为并发编程中的一大利器,其重要性不言而喻。今天,我将以对话的方式,带你一步步深入线程池的奥秘,从概述到功能点,再到背景和业务点,最后到底层原理和示例,让你对线程池有一个全新的认识。
50 12
|
16天前
|
监控 算法 Linux
Linux内核锁机制深度剖析与实践优化####
本文作为一篇技术性文章,深入探讨了Linux操作系统内核中锁机制的工作原理、类型及其在并发控制中的应用,旨在为开发者提供关于如何有效利用这些工具来提升系统性能和稳定性的见解。不同于常规摘要的概述性质,本文将直接通过具体案例分析,展示在不同场景下选择合适的锁策略对于解决竞争条件、死锁问题的重要性,以及如何根据实际需求调整锁的粒度以达到最佳效果,为读者呈现一份实用性强的实践指南。 ####
|
21天前
|
消息中间件 安全 Linux
深入探索Linux操作系统的内核机制
本文旨在为读者提供一个关于Linux操作系统内核机制的全面解析。通过探讨Linux内核的设计哲学、核心组件、以及其如何高效地管理硬件资源和系统操作,本文揭示了Linux之所以成为众多开发者和组织首选操作系统的原因。不同于常规摘要,此处我们不涉及具体代码或技术细节,而是从宏观的角度审视Linux内核的架构和功能,为对Linux感兴趣的读者提供一个高层次的理解框架。
|
22天前
|
缓存 并行计算 Linux
深入解析Linux操作系统的内核优化策略
本文旨在探讨Linux操作系统内核的优化策略,包括内核参数调整、内存管理、CPU调度以及文件系统性能提升等方面。通过对这些关键领域的分析,我们可以理解如何有效地提高Linux系统的性能和稳定性,从而为用户提供更加流畅和高效的计算体验。
29 2
|
28天前
|
算法 Linux 开发者
Linux内核中的锁机制:保障并发控制的艺术####
本文深入探讨了Linux操作系统内核中实现的多种锁机制,包括自旋锁、互斥锁、读写锁等,旨在揭示这些同步原语如何高效地解决资源竞争问题,保证系统的稳定性和性能。通过分析不同锁机制的工作原理及应用场景,本文为开发者提供了在高并发环境下进行有效并发控制的实用指南。 ####
|
16天前
|
存储 Oracle 安全
服务器数据恢复—LINUX系统删除/格式化的数据恢复流程
Linux操作系统是世界上流行的操作系统之一,被广泛用于服务器、个人电脑、移动设备和嵌入式系统。Linux系统下数据被误删除或者误格式化的问题非常普遍。下面北亚企安数据恢复工程师简单聊一下基于linux的文件系统(EXT2/EXT3/EXT4/Reiserfs/Xfs) 下删除或者格式化的数据恢复流程和可行性。
|
29天前
|
安全 Linux 数据安全/隐私保护
深入探索Linux操作系统的多用户管理机制
【10月更文挑战第21天】 本文将详细解析Linux操作系统中的多用户管理机制,包括用户账户的创建与管理、权限控制以及用户组的概念和应用。通过具体实例和命令操作,帮助读者理解并掌握Linux在多用户环境下如何实现有效的资源分配和安全管理。
下一篇
DataWorks