在系统中,随着我们的进程越来越多,难免不同进程之间要互相传输一些数据,那么这个时候该怎么办呢?
下面主要简单了解一下,进程间通信(InterProcess Communication,IPC)的几种实现方式!
1、管道模型
管道模型与软件生命周期模型——瀑布模型(Waterfall Model)很相似。
所谓的瀑布模型,其实就是将整个软件开发过程分成多个阶段,往往是上一个阶段完全做完,才将输出结果交给下一个阶段。
image-20220922134815245还记得咱们最初学 Linux 命令的时候,有下面这样一行命令:
ps -ef | grep 关键字 | awk '{print $2}' | xargs kill -9
这里面的竖线“|”就是一个管道。它会将前一个命令的输出,作为后一个命令的输入。
从管道的这个名称可以看出来,管道是一种单向传输数据的机制,它其实是一段缓存,里面的数据只能从一端写入,从另一端读出。如果想互相通信,我们需要创建两个管道才行。
管道又可以分为匿名管道和命名管道!
1.1 匿名管道
如上命令:
ps -ef | grep 关键字 | awk '{print $2}' | xargs kill -9
匿名管道:用"|” 表示的管道,意思就是这个类型的管道没有名字,用完了就销毁了。竖线代表的管道随着命令的执行自动创建、自动销毁。用户甚至都不知道自己在用管道这种技术,就已经解决了问题。
1.2 命名管道
命名管道,这个类型的管道需要通过 mkfifo
命令显式地创建。
mkfifo donge#建立一个管道
donge
就是这个管道的名称。管道以文件的形式存在,这也符合 Linux 里面一切皆文件的原则。
下面我们看一下文件类型
ls -l
prw-rw-r-- 1 dong dong 0 Sep 28 17:09 donge
可以看到,这个文件的类型是 p
,就是 pipe
的意思。
往管道中写入数据
echo "hello world" > donge
这个时候,管道里面的内容没有被读出,这个命令就是停在这里的,即进程被堵塞。
这说明当一个项目组要把它的输出交接给另一个项目组做输入,当没有交接完毕的时候,前一个项目组是不能撒手不管的。
重新打开一个终端,读出管道数据
cat < hello
hello world
一方面,我们能够看到,管道里面的内容被读取出来,打印到了终端上;
另一方面,echo 那个命令正常退出了,也即交接完毕,前一个项目组就完成了使命,可以解散了。
管道通信,我们可以看出,瀑布模型的开发流程效率比较低下,因为团队之间无法频繁地沟通。而且,管道的使用模式,也不适合进程间频繁的交换数据。
2、消息队列
image-20220922135603302消息队列可以理解为发邮件,每一封邮件都视为一个独立的数据单元,也就是消息体,每个消息体都是固定大小的存储块,在字节流上不连续。
这个消息结构的定义我写在下面了。这里面的类型 type 和正文 text 没有强制规定,只要消息的发送方和接收方约定好即可。
struct msg_buffer {
long mtype;
char mtext[1024];
};
2.1 创建消息队列
消息队列的创建,需要用到msgget
函数
int msgget(key_t key, int msgflg);
-
key
:该参数是消息队列的唯一标识,由ftok
生成。 -
msgflg
:取值有以下几个选择:IPC_CREAT
、IPC_EXCL
,这两个参数详细的作用可以man msgflg
看详细介绍。 -
返回值:返回一个近乎唯一的
Message queue id
那么,
key
是如何由ftok
生成的呢?
我们可以指定一个文件,调用ftok
,它会根据这个文件的 inode
,生成一个近乎唯一的 key
。
key_t ftok(const char *pathname, int proj_id);
-
pathname
:文件信息,必须指定在一个存在的,可访问的文件 -
proj_id
:8bit
的数据,0-255
随意设定
这样就可以获得一个近乎唯一的key
了!
只要在这个消息队列的生命周期内,这个文件不要被删除就可以了。只要不删除,无论什么时刻,再调用 ftok,也会得到同样的 key。
综上,创建一个消息队列只需两步:
①:ftok
生成一个key
②:msgget
生成一个消息队列的ID
如下:
#include
#include
#include
int main() {
int messagequeueid;
key_t key;
if((key = ftok("/root/messagequeue/messagequeuekey", 1)) < 0)
{
perror("ftok error");
exit(1);
}
printf("Message Queue key: %d.
", key);
if ((messagequeueid = msgget(key, IPC_CREAT|0777)) == -1)
{
perror("msgget error");
exit(1);
}
printf("Message queue id: %d.
", messagequeueid);
}
ftok
要指定一个存在的文件,所以我们在执行之前,需要创建该文件。
查看消息队列
System V IPC 体系有一个统一的命令行工具:
ipcmk
,ipcs
和ipcrm
用于创建、查看和删除IPC
对象。
查看创建的IPC
对象:ipcs -q
dong@ubuntu:~//Interprocess_Communication$ ipcs
------ Message Queues --------
key msqid owner perms used-bytes messages
0x01110005 0 dong 777 0 0
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Semaphore Arrays --------
key semid owner perms nsems
2.2 发送消息
消息队列发送消息,主要调用msgsnd
函数
int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
-
msqid
:该参数是msgget
所得到的message queue
的id
-
msgp
:消息结构体
struct msg_buffer {
long mtype;
char mtext[1024];
};
-
msgsz
:表示消息结构体中,mtext
最大长度 -
msgflg
:一位掩码,可取值有:IPC_NOWAIT
、MSG_COPY
、MSG_EXCEPT
、MSG_NOERROR
,取值说明可见man msgsnd
2.3 接收消息
消息队列接收消息,主要调用msgrcv
函数
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp,
int msgflg);
-
msqid
:该参数是msgget
所得到的message queue
的id
-
msgp
:消息结构体 -
msgsz
:可接收数据最大长度 -
msgflg
:一位掩码,可取值有:IPC_NOWAIT
、MSG_COPY
、MSG_EXCEPT
、MSG_NOERROR
,取值说明可见man msgsnd
有了消息这种模型,两个进程之间的通信就像咱们平时发邮件一样,你来一封,我回一封,可以频繁沟通了。
3、共享内存
image-20220924172026172怎么理解共享内存呢?
我们知道每个进程都有自己独立的虚拟内存空间,不同的进程的虚拟内存空间映射到不同的物理内存中去。这个进程访问 A 地址和另一个进程访问 A 地址,其实访问的是不同的物理内存地址,对于数据的增删查改互不影响。
但是,咱们是不是可以变通一下,拿出一块虚拟地址空间来,映射到相同的物理内存中。这样这个进程写入的东西,另外一个进程马上就能看到了,都不需要拷贝来拷贝去,传来传去。
相比于消息队列,共享内存的优势在哪里呢?
- 大数据传输:如果批量的大数据进行传输,使用邮件的方式,来去发送不及时,并且大小也有限制
- 实时性:用共享内存,其可以大大节省通信时间
3.1 创建共享内存
我们可以创建一个共享内存,调用 shmget
。
int shmget(key_t key, size_t size, int shmflg);
-
key
:和msgget
里面的key
一样,都是唯一定位一个共享内存的对象 -
size
:共享内存的大小 -
shmflg
:其值可以取:IPC_CREAT
、IPC_EXCL
、SHM_HUGETLB
、SHM_HUGE_2MB
等
返回值:共享内存的唯一ID
创建完毕之后,我们可以通过 ipcs
命令查看这个共享内存。
#ipcs --shmems
------ Shared Memory Segments ------
key shmid owner perms bytes nattch status
0x00000000 19398656 marc 600 1048576 2 dest
3.2 访问共享内存
接下来,如果一个进程想要访问这一段共享内存,需要将这个内存加载到自己的虚拟地址空间的某个位置,通过 shmat
函数,就是 attach
的意思。
void *shmat(int shmid, const void *shmaddr, int shmflg);
-
shmid
:标识一个共享内存段的唯一ID -
shmaddr
:就是要指定attach
到这个地方。但是这个地址的设定难度比较大,除非对于内存布局非常熟悉,否则可能会attach
到一个非法地址。所以,通常的做法是将shmaddr
设为NULL
,让内核选一个合适的地址。 -
shmflg
:一位掩码,可取值:SHM_EXEC
、SHM_RDONLY
、SHM_REMAP
。
返回值:为所连接的实际地址
3.3 关闭共享内存
如果共享内存使用完毕,可以通过 shmdt
解除绑定,然后通过 shmctl
,将 cmd
设置为 IPC_RMID
,从而删除这个共享内存对象。
int shmdt(void *addr);
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
shmdt
的参数addr
:为shmat
的返回值,表示卸载一片共享内存
shmctl
的参数:
-
shm_id
:shmget
的返回值,为共享内存的唯一ID -
cmd
:取值有:IPC_STAT
、IPC_RMID
等,见:man shmctl
-
buf
:共享内存管理结构体。
3.4 信号量
这里你是不是有一个疑问,如果两个进程 attach
同一个共享内存,大家都往里面写东西,很有可能就冲突了。例如两个进程都同时写一个地址,那先写的那个进程会发现内容被别人覆盖了。
所以,这里就需要一种保护机制,使得同一个共享的资源,同时只能被一个进程访问。在 System V IPC
进程间通信机制体系中,早就想好了应对办法,就是信号量(Semaphore
)。因此,信号量和共享内存往往要配合使用。
信号量和共享内存都比较复杂,两者还要结合起来用,就更加复杂,它们内核的机制就更加复杂。这一节我们先不讲。
4、信号
上面讲的进程间通信的方式,都是常规状态下的工作模式,对应到咱们平时的工作交接,收发邮件、联合开发等,其实还有一种异常情况下的工作模式。
例如出现线上系统故障,这个时候,什么流程都来不及了,不可能发邮件,也来不及开会,所有的架构师、开发、运维都要被通知紧急出动。所以,7 乘 24 小时不间断执行的系统都需要有告警系统,一旦出事情,就要通知到人,哪怕是半夜,也要电话叫起来,处理故障。
信号可以在任何时候发送给某一进程,进程需要为这个信号配置信号处理函数。
Linux
所支持的异常信号如下:
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX
当某个信号发生的时候,就默认执行这个函数就可以了。这就相当于咱们运维一个系统应急手册,当遇到什么情况,做什么事情,都事先准备好,出了事情照着做就可以了。
有点类似于异常中断……
审核编辑:郭婷
-
数据
+关注
关注
8文章
6989浏览量
88932 -
进程
+关注
关注
0文章
203浏览量
13958
原文标题:原来\进程间通信/是这么回事......
文章出处:【微信号:zhuyandz,微信公众号:FPGA之家】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论