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手冊