Linux环境进程间通讯(三)：消息队列

linux下进程间通讯的几种主要手段：

1. 管道（Pipe）及有名管道（named pipe）：管道可用于具备亲缘关系进程间的通讯，有名管道克服了管道没有名字的限制，所以，除具备管道所具备的功能外，它还容许无亲缘关系进程间的通讯； 
2. 信号（Signal）：信号是比较复杂的通讯方式，用于通知接受进程有某种事件发生，除了用于进程间通讯外，进程还能够发送信号给进程自己；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又可以统一对外接口，用sigaction函数从新实现了signal函数）； 
3. 报文（Message）队列（消息队列）：消息队列是消息的连接表，包括Posix消息队列system V消息队列。有足够权限的进程能够向队列中添加消息，被赋予读权限的进程则能够读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。 
4. 共享内存：使得多个进程能够访问同一块内存空间，是最快的可用IPC形式。是针对其余通讯机制运行效率较低而设计的。每每与其它通讯机制，如信号量结合使用，来达到进程间的同步及互斥。 
5. 信号量（semaphore）：主要做为进程间以及同一进程不一样线程之间的同步手段。 
6. 套接口（Socket）：更为通常的进程间通讯机制，可用于不一样机器之间的进程间通讯。起初是由Unix系统的BSD分支开发出来的，但如今通常能够移植到其它类Unix系统上：Linux和System V的变种都支持套接字。 

---

本文讲述进程间通讯方法——消息队列

原文：https://www.ibm.com/developerworks/cn/linux/l-ipc/part3/

消息队列（也叫作报文队列）可以克服早期unix通讯机制的一些缺点。做为早期unix通讯机制之一的信号可以传送的信息量有限，后来虽然POSIX 1003.1b在信号的实时性方面做了拓广，使得信号在传递信息量方面有了至关程度的改进，可是信号这种通讯方式更像"即时"的通讯方式，它要求接受信号的进程在某个时间范围内对信号作出反应，所以该信号最多在接受信号进程的生命周期内才有意义，信号所传递的信息是接近于随进程持续的概念（process-persistent），见 附录 1；管道及有名管道及有名管道则是典型的随进程持续IPC，而且，只能传送无格式的字节流无疑会给应用程序开发带来不便，另外，它的缓冲区大小也受到限制。

消息队列就是一个消息的链表。能够把消息看做一个记录，具备特定的格式以及特定的优先级。对消息队列有写权限的进程能够向中按照必定的规则添加新消息；对消息队列有读权限的进程则能够从消息队列中读走消息。消息队列是随内核持续的（参见 附录 1）。

目前主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。考虑到程序的可移植性，新开发的应用程序应尽可能使用POSIX消息队列。

在本系列专题的序（深入理解Linux进程间通讯（IPC））中，提到对于消息队列、信号灯、以及共享内存区来讲，有两个实现版本：POSIX的以及系统V的。Linux内核（内核2.4.18）支持POSIX信号灯、POSIX共享内存区以及POSIX消息队列，但对于主流Linux发行版本之一redhad8.0（内核2.4.18），尚未提供对POSIX进程间通讯API的支持，不过应该只是时间上的事。

所以，本文将主要介绍系统V消息队列及其相应API。 在没有声明的状况下，如下讨论中指的都是系统V消息队列。

1、消息队列基本概念

1. 系统V消息队列是随内核持续的，只有在内核重起或者显示删除一个消息队列时，该消息队列才会真正被删除。所以系统中记录消息队列的数据结构（struct ipc_ids msg_ids）位于内核中，系统中的全部消息队列均可以在结构msg_ids中找到访问入口。
2. 消息队列就是一个消息的链表。每一个消息队列都有一个队列头，用结构struct msg_queue来描述（参见 附录 2）。队列头中包含了该消息队列的大量信息，包括消息队列键值、用户ID、组ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。读者能够访问这些信息，也能够设置其中的某些信息。
3. 下图说明了内核与消息队列是怎样创建起联系的： 
   其中：struct ipc_ids msg_ids是内核中记录消息队列的全局数据结构；struct msg_queue是每一个消息队列的队列头。 
    

从上图能够看出，全局数据结构 struct ipc_ids msg_ids 能够访问到每一个消息队列头的第一个成员：struct kern_ipc_perm；而每一个struct kern_ipc_perm可以与具体的消息队列对应起来是由于在该结构中，有一个key_t类型成员key，而key则惟一肯定一个消息队列。kern_ipc_perm结构以下：

struct kern_ipc_perm{ //内核中记录消息队列的全局数据结构msg_ids可以访问到该结构； key_t key; //该键值则惟一对应一个消息队列 uid_t uid; gid_t gid; uid_t cuid; gid_t cgid; mode_t mode; unsigned long seq; }

2、操做消息队列

对消息队列的操做无非有下面三种类型：

一、 打开或建立消息队列 
消息队列的内核持续性要求每一个消息队列都在系统范围内对应惟一的键值，因此，要得到一个消息队列的描述字，只需提供该消息队列的键值便可；

注：消息队列描述字是由在系统范围内惟一的键值生成的，而键值能够看做对应系统内的一条路经。

二、 读写操做

消息读写操做很是简单，对开发人员来讲，每一个消息都相似以下的数据结构：

struct msgbuf{ long mtype; char mtext[1]; };

mtype成员表明消息类型，从消息队列中读取消息的一个重要依据就是消息的类型；mtext是消息内容，固然长度不必定为1。所以，对于发送消息来讲，首先预置一个msgbuf缓冲区并写入消息类型和内容，调用相应的发送函数便可；对读取消息来讲，首先分配这样一个msgbuf缓冲区，而后把消息读入该缓冲区便可。

三、 得到或设置消息队列属性：

消息队列的信息基本上都保存在消息队列头中，所以，能够分配一个相似于消息队列头的结构(struct msqid_ds，见 附录 2)，来返回消息队列的属性；一样能够设置该数据结构。

 
消息队列API

一、文件名到键值

#include <sys/types.h> #include <sys/ipc.h> key_t ftok (char*pathname, char proj)；

它返回与路径pathname相对应的一个键值。该函数不直接对消息队列操做，但在调用ipc(MSGGET,…)或msgget()来得到消息队列描述字前，每每要调用该函数。典型的调用代码是：

key=ftok(path_ptr, 'a'); ipc_id=ipc(MSGGET, (int)key, flags,0,NULL,0); …

二、linux为操做系统V进程间通讯的三种方式（消息队列、信号灯、共享内存区）提供了一个统一的用户界面： 

int ipc(unsigned int call, int first, int second, int third, void * ptr, long fifth);

第一个参数指明对IPC对象的操做方式，对消息队列而言共有四种操做：MSGSND、MSGRCV、MSGGET以及MSGCTL，分别表明向消息队列发送消息、从消息队列读取消息、打开或建立消息队列、控制消息队列；first参数表明惟一的IPC对象；下面将介绍四种操做。

• int ipc( MSGGET, intfirst, intsecond, intthird, void*ptr, longfifth); 
  与该操做对应的系统V调用为：int msgget( (key_t)first，second)。
• int ipc( MSGCTL, intfirst, intsecond, intthird, void*ptr, longfifth) 
  与该操做对应的系统V调用为：int msgctl( first，second, (struct msqid_ds*) ptr)。
• int ipc( MSGSND, intfirst, intsecond, intthird, void*ptr, longfifth); 
  与该操做对应的系统V调用为：int msgsnd( first, (struct msgbuf*)ptr, second, third)。
• int ipc( MSGRCV, intfirst, intsecond, intthird, void*ptr, longfifth); 
  与该操做对应的系统V调用为：int msgrcv( first，(struct msgbuf*)ptr, second, fifth,third)，

注：本人不主张采用系统调用ipc()，而更倾向于采用系统V或者POSIX进程间通讯API。缘由以下：

• 虽然该系统调用提供了统一的用户界面，但正是因为这个特性，它的参数几乎不能给出特定的实际意义（如以first、second来命名参数），在必定程度上形成开发不便。
• 正如ipc手册所说的：ipc()是linux所特有的，编写程序时应注意程序的移植性问题；
• 该系统调用的实现不过是把系统V IPC函数进行了封装，没有任何效率上的优点；
• 系统V在IPC方面的API数量很少，形式也较简洁。

3.系统V消息队列API 

系统V消息队列API共有四个，使用时须要包括几个头文件：

#include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h>

1）int msgget(key_t key, int msgflg)

参数key是一个键值，由ftok得到；msgflg参数是一些标志位。该调用返回与健值key相对应的消息队列描述字。

在如下两种状况下，该调用将建立一个新的消息队列：

• 若是没有消息队列与健值key相对应，而且msgflg中包含了IPC_CREAT标志位；
• key参数为IPC_PRIVATE；

参数msgflg能够为如下：IPC_CREAT、IPC_EXCL、IPC_NOWAIT或三者的或结果。

调用返回：成功返回消息队列描述字，不然返回-1。

注：参数key设置成常数IPC_PRIVATE并不意味着其余进程不能访问该消息队列，只意味着即将建立新的消息队列。

2）int msgrcv(int msqid, struct msgbuf *msgp, int msgsz, long msgtyp, int msgflg); 
该系统调用从msgid表明的消息队列中读取一个消息，并把消息存储在msgp指向的msgbuf结构中。

msqid为消息队列描述字；消息返回后存储在msgp指向的地址，msgsz指定msgbuf的mtext成员的长度（即消息内容的长度），msgtyp为请求读取的消息类型；读消息标志msgflg能够为如下几个常值的或：

• IPC_NOWAIT 若是没有知足条件的消息，调用当即返回，此时，errno=ENOMSG
• IPC_EXCEPT 与msgtyp>0配合使用，返回队列中第一个类型不为msgtyp的消息
• IPC_NOERROR 若是队列中知足条件的消息内容大于所请求的msgsz字节，则把该消息截断，截断部分将丢失。

msgrcv手册中详细给出了消息类型取不一样值时(>0; <0; =0)，调用将返回消息队列中的哪一个消息。

msgrcv()解除阻塞的条件有三个：

1. 消息队列中有了知足条件的消息；
2. msqid表明的消息队列被删除；
3. 调用msgrcv（）的进程被信号中断；

调用返回：成功返回读出消息的实际字节数，不然返回-1。

3）int msgsnd(int msqid, struct msgbuf *msgp, int msgsz, int msgflg); 
向msgid表明的消息队列发送一个消息，即将发送的消息存储在msgp指向的msgbuf结构中，消息的大小由msgze指定。

对发送消息来讲，有意义的msgflg标志为IPC_NOWAIT，指明在消息队列没有足够空间容纳要发送的消息时，msgsnd是否等待。形成msgsnd()等待的条件有两种：

• 当前消息的大小与当前消息队列中的字节数之和超过了消息队列的总容量；
• 当前消息队列的消息数（单位"个"）不小于消息队列的总容量（单位"字节数"），此时，虽然消息队列中的消息数目不少，但基本上都只有一个字节。

msgsnd()解除阻塞的条件有三个：

1. 不知足上述两个条件，即消息队列中有容纳该消息的空间；
2. msqid表明的消息队列被删除；
3. 调用msgsnd（）的进程被信号中断；

调用返回：成功返回0，不然返回-1。

4）int msgctl(int msqid, int cmd, struct msqid_ds *buf); 
该系统调用对由msqid标识的消息队列执行cmd操做，共有三种cmd操做：IPC_STAT、IPC_SET 、IPC_RMID。

1. IPC_STAT：该命令用来获取消息队列信息，返回的信息存贮在buf指向的msqid结构中；
2. IPC_SET：该命令用来设置消息队列的属性，要设置的属性存储在buf指向的msqid结构中；可设置属性包括：msg_perm.uid、msg_perm.gid、msg_perm.mode以及msg_qbytes，同时，也影响msg_ctime成员。
3. IPC_RMID：删除msqid标识的消息队列；

调用返回：成功返回0，不然返回-1。

3、消息队列的限制

每一个消息队列的容量（所能容纳的字节数）都有限制，该值因系统不一样而不一样。在后面的应用实例中，输出了redhat 8.0的限制，结果参见 附录 3。

另外一个限制是每一个消息队列所能容纳的最大消息数：在redhad 8.0中，该限制是受消息队列容量制约的：消息个数要小于消息队列的容量（字节数）。

注：上述两个限制是针对每一个消息队列而言的，系统对消息队列的限制还有系统范围内的最大消息队列个数，以及整个系统范围内的最大消息数。通常来讲，实际开发过程当中不会超过这个限制。

4、消息队列应用实例

消息队列应用相对较简单，下面实例基本上覆盖了对消息队列的全部操做，同时，程序输出结果有助于加深对前面所讲的某些规则及消息队列限制的理解。

#include <sys/types.h> #include <sys/msg.h> #include <unistd.h> void msg_stat(int,struct msqid_ds ); main() { int gflags,sflags,rflags; key_t key; int msgid; int reval; struct msgsbuf{ int mtype; char mtext[1]; }msg_sbuf; struct msgmbuf { int mtype; char mtext[10]; }msg_rbuf; struct msqid_ds msg_ginfo,msg_sinfo; char* msgpath="/unix/msgqueue"; key=ftok(msgpath,'a'); gflags=IPC_CREAT|IPC_EXCL; msgid=msgget(key,gflags|00666); if(msgid==-1) { printf("msg create error\n"); return; } //建立一个消息队列后，输出消息队列缺省属性 msg_stat(msgid,msg_ginfo); sflags=IPC_NOWAIT; msg_sbuf.mtype=10; msg_sbuf.mtext[0]='a'; reval=msgsnd(msgid,&msg_sbuf,sizeof(msg_sbuf.mtext),sflags); if(reval==-1) { printf("message send error\n"); } //发送一个消息后，输出消息队列属性 msg_stat(msgid,msg_ginfo); rflags=IPC_NOWAIT|MSG_NOERROR; reval=msgrcv(msgid,&msg_rbuf,4,10,rflags); if(reval==-1) printf("read msg error\n"); else printf("read from msg queue %d bytes\n",reval); //从消息队列中读出消息后，输出消息队列属性 msg_stat(msgid,msg_ginfo); msg_sinfo.msg_perm.uid=8;//just a try msg_sinfo.msg_perm.gid=8;// msg_sinfo.msg_qbytes=16388; //此处验证超级用户能够更改消息队列的缺省msg_qbytes //注意这里设置的值大于缺省值 reval=msgctl(msgid,IPC_SET,&msg_sinfo); if(reval==-1) { printf("msg set info error\n"); return; } msg_stat(msgid,msg_ginfo); //验证设置消息队列属性 reval=msgctl(msgid,IPC_RMID,NULL);//删除消息队列 if(reval==-1) { printf("unlink msg queue error\n"); return; } } void msg_stat(int msgid,struct msqid_ds msg_info) { int reval; sleep(1);//只是为了后面输出时间的方便 reval=msgctl(msgid,IPC_STAT,&msg_info); if(reval==-1) { printf("get msg info error\n"); return; } printf("\n"); printf("current number of bytes on queue is %d\n",msg_info.msg_cbytes); printf("number of messages in queue is %d\n",msg_info.msg_qnum); printf("max number of bytes on queue is %d\n",msg_info.msg_qbytes); //每一个消息队列的容量（字节数）都有限制MSGMNB，值的大小因系统而异。在建立新的消息队列时，//msg_qbytes的缺省值就是MSGMNB printf("pid of last msgsnd is %d\n",msg_info.msg_lspid); printf("pid of last msgrcv is %d\n",msg_info.msg_lrpid); printf("last msgsnd time is %s", ctime(&(msg_info.msg_stime))); printf("last msgrcv time is %s", ctime(&(msg_info.msg_rtime))); printf("last change time is %s", ctime(&(msg_info.msg_ctime))); printf("msg uid is %d\n",msg_info.msg_perm.uid); printf("msg gid is %d\n",msg_info.msg_perm.gid); }

程序输出结果见 附录 3。

小结：

消息队列与管道以及有名管道相比，具备更大的灵活性，首先，它提供有格式字节流，有利于减小开发人员的工做量；其次，消息具备类型，在实际应用中，可做为优先级使用。这两点是管道以及有名管道所不能比的。一样，消息队列能够在几个进程间复用，而无论这几个进程是否具备亲缘关系，这一点与有名管道很类似；但消息队列是随内核持续的，与有名管道（随进程持续）相比，生命力更强，应用空间更大。

附录 1： 在参考文献[1]中，给出了IPC随进程持续、随内核持续以及随文件系统持续的定义：

1. 随进程持续：IPC一直存在到打开IPC对象的最后一个进程关闭该对象为止。如管道和有名管道；
2. 随内核持续：IPC一直持续到内核从新自举或者显示删除该对象为止。如消息队列、信号灯以及共享内存等；
3. 随文件系统持续：IPC一直持续到显示删除该对象为止。

附录 2： 

结构msg_queue用来描述消息队列头，存在于系统空间：

struct msg_queue { struct kern_ipc_perm q_perm; time_t q_stime; /* last msgsnd time */ time_t q_rtime; /* last msgrcv time */ time_t q_ctime; /* last change time */ unsigned long q_cbytes; /* current number of bytes on queue */ unsigned long q_qnum; /* number of messages in queue */ unsigned long q_qbytes; /* max number of bytes on queue */ pid_t q_lspid; /* pid of last msgsnd */ pid_t q_lrpid; /* last receive pid */ struct list_head q_messages; struct list_head q_receivers; struct list_head q_senders; };

结构msqid_ds用来设置或返回消息队列的信息，存在于用户空间；

struct msqid_ds { struct ipc_perm msg_perm; struct msg *msg_first; /* first message on queue,unused */ struct msg *msg_last; /* last message in queue,unused */ __kernel_time_t msg_stime; /* last msgsnd time */ __kernel_time_t msg_rtime; /* last msgrcv time */ __kernel_time_t msg_ctime; /* last change time */ unsigned long msg_lcbytes; /* Reuse junk fields for 32 bit */ unsigned long msg_lqbytes; /* ditto */ unsigned short msg_cbytes; /* current number of bytes on queue */ unsigned short msg_qnum; /* number of messages in queue */ unsigned short msg_qbytes; /* max number of bytes on queue */ __kernel_ipc_pid_t msg_lspid; /* pid of last msgsnd */ __kernel_ipc_pid_t msg_lrpid; /* last receive pid */ };

//能够看出上述两个结构很类似。

附录 3： 消息队列实例输出结果：

current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16384 pid of last msgsnd is 0 pid of last msgrcv is 0 last msgsnd time is Thu Jan 1 08:00:00 1970 last msgrcv time is Thu Jan 1 08:00:00 1970 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 //上面刚刚建立一个新消息队列时的输出 current number of bytes on queue is 1 number of messages in queue is 1 max number of bytes on queue is 16384 pid of last msgsnd is 2510 pid of last msgrcv is 0 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Thu Jan 1 08:00:00 1970 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 read from msg queue 1 bytes //实际读出的字节数 current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16384 //每一个消息队列最大容量（字节数） pid of last msgsnd is 2510 pid of last msgrcv is 2510 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Sun Dec 29 18:28:22 2002 last change time is Sun Dec 29 18:28:20 2002 msg uid is 0 msg gid is 0 current number of bytes on queue is 0 number of messages in queue is 0 max number of bytes on queue is 16388 //可看出超级用户可修改消息队列最大容量 pid of last msgsnd is 2510 pid of last msgrcv is 2510 //对操做消息队列进程的跟踪 last msgsnd time is Sun Dec 29 18:28:21 2002 last msgrcv time is Sun Dec 29 18:28:22 2002 last change time is Sun Dec 29 18:28:23 2002 //msgctl()调用对msg_ctime有影响 msg uid is 8 msg gid is 8

参考资料

• UNIX网络编程第二卷：进程间通讯，做者：W.Richard Stevens，译者：杨继张，清华大学出版社。对POSIX以及系统V消息队列都有阐述，对Linux环境下的程序开发有极大的启发意义。
• linux内核源代码情景分析（上），毛德操、胡希明著，浙江大学出版社，给出了系统V消息队列相关的源代码分析。
  
  
• http://www.fanqiang.com/a4/b2/20010508/113315.html，主要阐述linux下对文件的操做，详细介绍了对文件的存取权限位，对IPC对象的存取权限一样具备很好的借鉴意义。 
• msgget、msgsnd、msgrcv、msgctl手册