mqtt应用于进程间通信实例解析丨【拜托了,物联网!】
650
2022-05-29
@[toc]
管道
匿名管道
在shell中管道用 “|” 表示。
可以理解为内存中的一个缓冲区,用于将某个进程的数据流导入,由某一个进程导出,实现通信。
这种管道称为“匿名管道”,用完即毁。
匿名管道是特殊的文件,只存在于内存之中,不存在于文件系统中。
匿名管道用于有血缘关系的进程间通信。
这种血缘关系不一定要是父子关系,在 shell 里面执行 A | B命令的时候,A 进程和 B 进程都是 shell 创建出来的子进程,A 和 B 之间不存在父子关系,它俩的父进程都是 shell。
如果要用管道进行无血缘关系之间的进程通信,用FIFO有名管道。
局势到这里已经很清楚了,管道具有:“召之即来,挥之即去,且不占文件系统位置”的特性,适合用于shell中的“一次性博弈”。
如果是“长期博弈”,它不行,得往后看。
使用管道注意以下四种情况(假设都是阻塞I/O操作):
1、两个写端都被阻塞。read会返回0。
2、两个读端都被阻塞。这时有进程向管道的写端write,那么该进程会收到信号SIGPIPE,通常会导致进程异常终止。
3、正常开放,但是只读不写。读完了就开始阻塞。
4、正常开放,但是只写不读。管道写满了就阻塞了。
管道PIPE_BUF说明
可以使用linux的ulimit -a来查看系统限制。
POSIX.1要求PIPE_BUF至少为512字节。(在Linux上,PIPE_BUF为4096字节)。在实践中取决于文件描述符是否为非阻塞(O_NONBLOCK),管道中是否有多个写入器,以及n要写入的字节数:
情况1:O_NONBLOCK disabled, n <= PIPE_BUF 所有n个字节都以原子方式写入; write可能会阻止如果没有空间来立即写入n个字节。 情况2:O_NONBLOCK enabled, n <= PIPE_BUF 如果有空间向管道写入n个字节,则立即write成功,写入全部n个字节; 否则失败,并将errno设置为EAGAIN。 情况3:O_NONBLOCK disabled, n > PIPE_BUF 写入是非原子化的:write的数据可能会被写入与其他进程交错; write阻塞,直到写入了n个字节。 情况4:O_NONBLOCK enabled, n > PIPE_BUF 如果管道已满,则写入失败,并将errno设置为EAGAIN。 否则,可能会写入1到n个字节(即可能发生“部分写入”;调用者应该检查write(2)的返回值以查看实际写入的字节数),并且可以将这些字节与其他进程写入。
有名管道
通信可以是双向的,并且父子关系不是必需的,当建立了一个有名管道后,多个进程都可用它通信。
一旦创建,它们表现为文件系统的典型文件。通过系统调用 mkfifo(),可以创建 FIFO,通过系统调用 open()、read()、write()和close(),可以操作 FIFO。
虽然 FIFO 允许双向通信,但只允许半双工传输
数据在同一时间内只能按一个方向传输,程序不能以O_RDWR(读写)模式打开FIFO文件进行读写操作,因为如一个管道以读/写方式打开,进程就会读回自己的输出。如果数据要在两个方向上传输,那么通常使用两个 FIFO。
与 UNIX 系统相比,Windows 系统的有名管道通信机制更加丰富。
对于以只读方式(O_RDONLY)打开的FIFO文件,如果open调用是阻塞的(即第二个参数为O_RDONLY),除非有一个进程以写方式打开同一个FIFO,否则它不会返回;如果open调用是非阻塞的的(即第二个参数为O_RDONLY | O_NONBLOCK),则即使没有其他进程以写方式打开同一个FIFO文件,open调用将成功并立即返回。
对于以只写方式(O_WRONLY)打开的FIFO文件,如果open调用是阻塞的(即第二个参数为O_WRONLY),open调用将被阻塞,直到有一个进程以只读方式打开同一个FIFO文件为止;如果open调用是非阻塞的(即第二个参数为O_WRONLY | O_NONBLOCK),open总会立即返回,但如果没有其他进程以只读方式打开同一个FIFO文件,open调用将返回-1,并且FIFO也不会被打开。
有一种情况是:一个FIFO文件,有多个进程同时向同一个FIFO文件写数据,而只有一个读FIFO进程在同一个FIFO文件中读取数据时,会发生数据块的相互交错。不同进程向一个FIFO读进程发送数据是很普通的情况。这个问题的解决方法,就是让写操作的原子化。
有名管道,但当涉猎,感觉不上不下的,使用起来没有匿名管道简单,传输效率又没有共享内存快,内存吧又没mmap大,滞后性又不如消息队列,信号机制更不用说了。
消息队列
==一发一存一消费==
抛去那些已经成名的消息队列,
1、消息队列是内核地址空间中的内部链表,通过Linux内核在不同的进程间传递消息。 2、消息顺序的发送到消息队列中,并以几种不同的方式从队列中获取。 3、内核中的消息队列是==通过IPC标识符来进行区别==的,不同消息队列之间是==互相独立==的。 4、每个消息队列中的消息又构成一个独立的链表。 消息队列不适合比较大数据的传输,因为在内核中每个消息体都有一个最大长度的限制,同时所有队列所包含的全部消息体的总长度也是有上限。在 Linux 内核中,会有两个宏定义 MSGMAX 和 MSGMNB,它们以字节为单位,分别定义了一条消息的最大长度和一个队列的最大长度。
消息队列的优势还是很明显的,实现了业务层面的异步操作。
目前,MQ 的应用场景非常多,大家能倒背如流的是:系统解耦、异步通信和流量削峰。除此之外,还有延迟通知、最终一致性保证、顺序消息、流式处理等等。
关于消息队列的部分会在后面专门写有名消息队列的博客里续写。
共享内存
1、共享内存是在多个进程之间共享内存区域的一种进程间的通信方式。
2、它是在多个进程间通过对指定内存段进行映射实现内存共享的。
3、这是IPC最快捷的方式,因为它没有中间商赚差价。
4、多个进程间共享的是同一块==物理空间==,仅仅是挂载地址不同而已,因此不需要进行复制,可以直接使用这段空间。
代码操作
到了共享内存,不像前面两个,是时候来代码操作了。
#include
注意:内核是以页为单位分配内存,当size参数的值不是系统内存页长的整数倍时,系统会分配给进程最小的可以满足size长的页数,但是最后一页的剩余部分内存是不可用的。
key_t ftok(const char *pathname, int proj_id); 创建IPC通讯时所必需的ID值。 pathname:指定已经存在的文件名,一般是当前目录 proj_id:子序列号,正整数,差不多大小就好了,别乱设。 返回值:ID值,大小是文件的索引节点号前加上子序列号,例如:pathname索引节点号为0x101010,proj_id为0x32,则ID为0x32101010。
void *shmat(int shmid, const void *shmaddr, int shmflg); shmid:共享内存标识符,shmget() 的返回值。 shmaddr:共享内存映射地址(若为 NULL 则由系统自动指定),推荐使用 NULL。 shmflg:共享内存段的访问权限和映射条件( 通常为 0 ),具体取值如下: 0:共享内存具有可读可写权限。 SHM_RDONLY:只读。 SHM_RND:(shmaddr 非空时才有效) 函数执行成功返回共享内存的首地址,失败返回–1。shmat函数成功执行会将shm_id段的shmid_ds结构的shm_nattch计数器的值加1。
使用函数shmat将一个存在的共享内存段连接到本进程空间,函数中参数shm_id指定要引入的共享内存,参数addr与flag组合说明要引入的地址值,通常只有2种用法,addr为0,表明让内核来决定第1个可以引入的位置。addr非零,并且flag中指定SHM_RND,则此段引入到addr所指向的位置(此操作不推荐使用,因为不会只对一种硬件上运行应用程序,为了程序的通用性推荐使用第1种方法),在flag参数中可以指定要引入的方式(读写方式指定)。
注:fork后子进程继承已连接的共享内存地址。exec后该子进程与已连接的共享内存地址自动脱离(detach)。进程结束后,已连接的共享内存地址会自动脱离(detach)
/* 将共享内存和当前进程分离(仅仅是断开联系并不删除共享内存,相当于让之前的指向此共享内存的指针,不再指向)。*/ #include
参数addr是调用shmat函数的返回值,函数执行成功返回0,并将该共享内存的shmid_ds结构的shm_nattch计数器减1,失败返回–1。
#include
注:IPC_RMID仅是将共享内存标记为删除。如果共享内存仅有当前进程连接,则直接删除。如果还有其他进程,则会将当前进程从连接中删除,并且将共享内存标识符改为0,表明其为PRIVATE状态,阻止其他进程再连接共享内存,等待其他进程断开连接后删除共享内存。
struct shmid_ds { struct ipc_perm msg_perm; //后面写 size_t shm_segsz; //段大小,以字节为单位 time_t shm_atime; //最后挂载时间 time_t shm_dtime; //最后卸载时间 time_t shm_ctime; //最后修改时间 pid_t shm_cpid; //建立者 pid_t shm_lpid; //最后一个at/dt操作的进程PID shmatt_t shm_nattch; //现挂载数量 ··· } //下面这个是关键 struct ipc_perm { key_t key; //键值 uid_t uid; gid_t gid; //用户GID uid_t cuid; gid_t cgid; //建立者GID unsigned short mode;//权限 unsigned short seq; //序列号 }
写端示例:
/* study.cpp 写端代码 */ #include
读端:
/* main.c 读端代码 */ #include
并发场景下的共享内存
它没有提供进程间同步和互斥的功能。所以,共享内存通常是要与信号量结合使用。
文件映射
虚拟空间 && 虚拟内存
from:https://www.zhihu.com/question/48161206
看到有的地方将虚拟空间和虚拟内存混在一起讲了,还是先把这个捋清楚。还有虚拟内存?那数据写下去不是“拳拳到肉”吗?那我4G内核怎么写40G数据进去啊?
虚拟地址 != 虚拟内存 虚拟内存 == 不存在的
在开发中没有意义。开发中只有虚拟空间的概念,进程看到的所有地址组成的空间,就是虚拟空间。虚拟空间是某个进程对分配给它的所有物理地址(已经分配的和将会分配的)的重新映射。
“mmap的作用,在应用这一层,==是让你把文件的某一段,当作内存一样来访问==。内核和驱动如何实现的,性能高不高这些问题,这层语义上没有承诺。你基于功能决定怎么用它就好了,少胡思乱想。”
虚拟空间可以很大,但不表示物理内存也需要很大。每个进程有自己的虚拟空间(切换进程的时候切换MMU的翻译表即可),这些虚拟空间可以映射到物理内存的不同或者相同的位置。示意如下:
Linux执行一个程序,这个程序在磁盘上,为了执行这个程序,需要把程序加载到内存中,这时采用的就是mmap,mmap让虚拟空间和文件的内容组成的空间(我这里称为文件空间)对应,类似这样:
上面展示的是mmap之后的效果,但文件的内容在磁盘上是不能被CPU访问的,所以当CPU真的在这个地址上发起读写执行等操作时,OS会进入异常,异常中会调用文件系统把一页或者多页的文件内容加载到物理内存中,这会变成这样:
mmap内存映射原理
from:https://blog.csdn.net/qq_33611327/article/details/81738195
mmap将一个文件或者其它对象映射进内存。文件被映射到多个页上,如果文件的大小不是所有页的大小之和,最后一个页不被使用的空间将会清零。
mmap的特点是==按需调页==。最开始只申请vma,并不调真正的页。当对某些页进行引用的时候,会引起一个缺页中断,再将页面调入到内存当中,这样避免了对内存的浪费。
函数原型也没有shm那么多,当然比后边那个socket也是更少的了。
mmap内存映射的实现过程,总的来说可以分为三个阶段:
(一)进程启动映射过程,并在虚拟地址空间中为映射创建虚拟映射区域
1、进程在用户空间调用库函数mmap, 原型:void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset); 2、在当前进程的虚拟地址空间中,寻找一段空闲的满足要求的连续的虚拟地址 3、为此虚拟区分配一个vm_area_struct结构,接着对这个结构的各个域进行了初始化 4、将新建的虚拟区结构(vm_area_struct)插入进程的虚拟地址区域链表或树中
(二)调用内核空间的系统调用函数mmap(不同于用户空间函数),实现文件物理地址和进程虚拟地址的一一映射关系
5、为映射分配了新的虚拟地址区域后,通过待映射的文件指针,在文件描述符表中找到对应的文件描述符, 通过文件描述符,链接到内核“已打开文件集”中该文件的文件结构体(struct file),每个文件结构体维护着和这个已打开文件相关各项信息。 6、通过该文件的文件结构体,链接到file_operations模块,调用内核函数mmap, 其原型为:int mmap(struct file *filp, struct vm_area_struct *vma),不同于用户空间库函数。 7、内核mmap函数通过虚拟文件系统inode模块定位到文件磁盘物理地址。 8、通过remap_pfn_range函数建立页表,即实现了文件地址和虚拟地址区域的映射关系。此时,这片虚拟地址并没有任何数据关联到主存中。
(三)进程发起对这片映射空间的访问,引发缺页异常,实现文件内容到物理内存(主存)的拷贝
注:前两个阶段仅在于创建虚拟区间并完成地址映射,但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。
9、进程的读或写操作访问虚拟地址空间这一段映射地址,通过查询页表,发现这一段地址并不在物理页面上。 因为目前只建立了地址映射,真正的硬盘数据还没有拷贝到内存中,因此引发缺页异常。 10、缺页异常进行一系列判断,确定无非法操作后,内核发起请求调页过程。 11、调页过程先在交换缓存空间(swap cache)中寻找需要访问的内存页,如果没有则调用nopage函数把所缺的页从磁盘装入到主存中。 12、之后进程即可对这片主存进行读或者写的操作,如果写操作改变了其内容,一定时间后系统会自动回写脏页面到对应磁盘地址,也即完成了写入到文件的过程。 注:修改过的脏页面并不会立即更新回文件中,而是有一段时间的延迟,可以调用msync()来强制同步, 这样所写的内容就能立即保存到文件里了。
mmap优点
由上文讨论可知,mmap优点共有一下几点:
1、对文件的读取操作跨过了页缓存,减少了数据的拷贝次数,用内存读写取代I/O读写,提高了文件读取效率。
2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内,从而被对方空间及时捕捉。
3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程,都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动,达到进程间通信和进程间共享的目的。
同时,如果进程A和进程B都映射了区域C,当A第一次读取C时通过缺页从磁盘复制文件页到内存中;但当B再读C的相同页面时,虽然也会产生缺页异常,但是不再需要从磁盘中复制文件过来,而可直接使用已经保存在内存中的文件数据。
4、可用于实现高效的大规模数据传输。内存空间不足,是制约大数据操作的一个方面,解决方案往往是借助硬盘空间协助操作,补充内存的不足。但是进一步会造成大量的文件I/O操作,极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说,但凡是需要用磁盘空间代替内存的时候,mmap都可以发挥其功效。
函数原型
#include
成功执行时,mmap()返回被映射区的指针,munmap()返回0。失败时,mmap()返回MAP_FAILED[其值为(void *)-1],munmap返回-1。errno被设为以下的某个值
EACCES:访问出错 EAGAIN:文件已被锁定,或者太多的内存已被锁定 EBADF:fd不是有效的文件描述词 EINVAL:一个或者多个参数无效 ENFILE:已达到系统对打开文件的限制 ENODEV:指定文件所在的文件系统不支持内存映射 ENOMEM:内存不足,或者进程已超出最大内存映射数量 EPERM:权能不足,操作不允许 ETXTBSY:已写的方式打开文件,同时指定MAP_DENYWRITE标志 SIGSEGV:试着向只读区写入 SIGBUS:试着访问不属于进程的内存区
mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后,进程可以像访问普通内存一样对文件进行访问,不必再调用read(),write()等操作。
注:实际上,mmap()系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式,进程可以像读写内存一样对普通文件的操作。而Posix或System V的共享内存IPC则纯粹用于共享目的,当然mmap()实现共享内存也是其主要应用之一。
mmap使用细节
1、使用mmap需要注意的一个关键点是,mmap映射区域大小必须是物理页大小(page_size)的整倍数(32位系统中通常是4k字节)。原因是,内存的最小粒度是页,而进程虚拟地址空间和内存的映射也是以页为单位。为了匹配内存的操作,mmap从磁盘到虚拟地址空间的映射也必须是页。
2、内核可以跟踪被内存映射的底层对象(文件)的大小,进程可以合法的访问在当前文件大小以内又在内存映射区以内的那些字节。也就是说,如果文件的大小一直在扩张,只要在映射区域范围内的数据,进程都可以合法得到,这和映射建立时文件的大小无关。具体情形参见“情形三”。
3、映射建立之后,即使文件关闭,映射依然存在。因为映射的是磁盘的地址,不是文件本身,和文件句柄无关。同时可用于进程间通信的有效地址空间不完全受限于被映射文件的大小,因为是按页映射。
在上面的知识前提下,我们下面看看如果大小不是页的整倍数的具体情况:
情形一:一个文件的大小是5000字节,mmap函数从一个文件的起始位置开始,映射5000字节到虚拟内存中。
分析:因为单位物理页面的大小是4096字节,虽然被映射的文件只有5000字节,但是对应到进程虚拟地址区域的大小需要满足整页大小,因此mmap函数执行后,实际映射到虚拟内存区域8192个 字节,5000~8191的字节部分用零填充。
此时:
(1)读/写前5000个字节(0~4999),会返回操作文件内容。
(2)读字节5000~8191时,结果全为0。写5000~8191时,进程不会报错,但是所写的内容不会写入原文件中 。
(3)读/写8192以外的磁盘部分,会返回一个SIGSECV错误。
情形二:一个文件的大小是5000字节,mmap函数从一个文件的起始位置开始,映射15000字节到虚拟内存中,即映射大小超过了原始文件的大小。
分析:由于文件的大小是5000字节,和情形一一样,其对应的两个物理页。那么这两个物理页都是合法可以读写的,只是超出5000的部分不会体现在原文件中。由于程序要求映射15000字节,而文件只占两个物理页,因此8192字节~15000字节都不能读写,操作时会返回异常。
此时:
(1)进程可以正常读/写被映射的前5000字节(0~4999),写操作的改动会在一定时间后反映在原文件中。
(2)对于5000~8191字节,进程可以进行读写过程,不会报错。但是内容在写入前均为0,另外,写入后不会反映在文件中。
(3)对于8192~14999字节,进程不能对其进行读写,会报SIGBUS错误。
(4)对于15000以外的字节,进程不能对其读写,会引发SIGSEGV错误。
情形三:一个文件初始大小为0,使用mmap操作映射了1000*4K的大小,即1000个物理页大约4M字节空间,mmap返回指针ptr。
分析:如果在映射建立之初,就对文件进行读写操作,由于文件大小为0,并没有合法的物理页对应,如同情形二一样,会返回SIGBUS错误。
但是如果,每次操作ptr读写前,先增加文件的大小,那么ptr在文件大小内部的操作就是合法的。例如,文件扩充4096字节,ptr就能操作ptr ~ [ (char)ptr + 4095]的空间。只要文件扩充的范围在1000个物理页(映射范围)内,ptr都可以对应操作相同的大小。
这样,方便随时扩充文件空间,随时写入文件,不造成空间浪费
性能?
都说不要胡思乱想了。
“
mmap之后,再有读操作不会经过系统调用,在 LRU 比较最近使用的页的时候不占优势;
于是,普通读情况下(排除反复读之类的文艺与2B读操作),read() 通常会比 mmap() 来得更快。
”
信号
累了,下次吧。
好吧,其实就是不会。
socket
后面会专门再整理一篇socket的,这里只是声明一下。
任务调度
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。