关注+星标公众号,不错过精彩内容
作者 | DonGe
来源 | 嵌入式艺术
在系统中,随着我们的进程越来越多,难免不同进程之间要互相传输一些数据,那么这个时候该怎么办呢?
下面主要简单了解一下,进程间通信(InterProcess Communication,IPC)的几种实现方式!
ps -ef | grep 关键字 | awk '{print $2}' | xargs kill -9
这里面的竖线“|”就是一个管道。它会将前一个命令的输出,作为后一个命令的输入。
如上命令:
ps -ef | grep 关键字 | awk '{print $2}' | xargs kill -9
命名管道,这个类型的管道需要通过 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
消息队列可以理解为发邮件,每一封邮件都视为一个独立的数据单元,也就是消息体,每个消息体都是固定大小的存储块,在字节流上不连续。
这个消息结构的定义我写在下面了。这里面的类型 type 和正文 text 没有强制规定,只要消息的发送方和接收方约定好即可。
struct msg_buffer {
long mtype;
char mtext[1024];
};
消息队列的创建,需要用到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.\n", key);
if ((messagequeueid = msgget(key, IPC_CREAT|0777)) == -1)
{
perror("msgget error");
exit(1);
}
printf("Message queue id: %d.\n", 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
消息队列发送消息,主要调用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
消息队列接收消息,主要调用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
有了消息这种模型,两个进程之间的通信就像咱们平时发邮件一样,你来一封,我回一封,可以频繁沟通了。
怎么理解共享内存呢?
我们知道每个进程都有自己独立的虚拟内存空间,不同的进程的虚拟内存空间映射到不同的物理内存中去。这个进程访问 A 地址和另一个进程访问 A 地址,其实访问的是不同的物理内存地址,对于数据的增删查改互不影响。
但是,咱们是不是可以变通一下,拿出一块虚拟地址空间来,映射到相同的物理内存中。这样这个进程写入的东西,另外一个进程马上就能看到了,都不需要拷贝来拷贝去,传来传去。
相比于消息队列,共享内存的优势在哪里呢?
我们可以创建一个共享内存,调用 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
接下来,如果一个进程想要访问这一段共享内存,需要将这个内存加载到自己的虚拟地址空间的某个位置,通过 shmat
函数,就是 attach
的意思。
void *shmat(int shmid, const void *shmaddr, int shmflg);
shmid
:标识一个共享内存段的唯一IDshmaddr
:就是要指定 attach
到这个地方。但是这个地址的设定难度比较大,除非对于内存布局非常熟悉,否则可能会 attach
到一个非法地址。所以,通常的做法是将 shmaddr
设为 NULL
,让内核选一个合适的地址。shmflg
:一位掩码,可取值:SHM_EXEC
、SHM_RDONLY
、SHM_REMAP
。返回值:为所连接的实际地址
如果共享内存使用完毕,可以通过 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
的返回值,为共享内存的唯一IDcmd
:取值有:IPC_STAT
、IPC_RMID
等,见:man shmctl
buf
:共享内存管理结构体。
这里你是不是有一个疑问,如果两个进程 attach
同一个共享内存,大家都往里面写东西,很有可能就冲突了。例如两个进程都同时写一个地址,那先写的那个进程会发现内容被别人覆盖了。
所以,这里就需要一种保护机制,使得同一个共享的资源,同时只能被一个进程访问。在 System V IPC
进程间通信机制体系中,早就想好了应对办法,就是信号量(Semaphore
)。因此,信号量和共享内存往往要配合使用。
信号量和共享内存都比较复杂,两者还要结合起来用,就更加复杂,它们内核的机制就更加复杂。这一节我们先不讲。
上面讲的进程间通信的方式,都是常规状态下的工作模式,对应到咱们平时的工作交接,收发邮件、联合开发等,其实还有一种异常情况下的工作模式。
例如出现线上系统故障,这个时候,什么流程都来不及了,不可能发邮件,也来不及开会,所有的架构师、开发、运维都要被通知紧急出动。所以,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
当某个信号发生的时候,就默认执行这个函数就可以了。这就相当于咱们运维一个系统应急手册,当遇到什么情况,做什么事情,都事先准备好,出了事情照着做就可以了。
有点类似于异常中断……
OK,这一篇就写到这里,希望对你有所帮助。
------------ END ------------
●专栏《嵌入式工具》
●专栏《嵌入式开发》
●专栏《Keil教程》
●嵌入式专栏精选教程
关注公众号回复“加群”按规则加入技术交流群,回复“1024”查看更多内容。