Linux環(huán)境進(jìn)程間通信(三):消息隊列
本系列文章中的前兩部分,我們探討管道及信號兩種通信機(jī)制,本文將深入第三部分,介紹系統(tǒng) V 消息隊列及其相應(yīng) API。
消息隊列(也叫做報文隊列)能夠克服早期unix通信機(jī)制的一些缺點(diǎn)。作為早期unix通信機(jī)制之一的信號能夠傳送的信息量有限,后來雖然POSIX 1003.1b在信號的實(shí)時性方面作了拓廣,使得信號在傳遞信息量方面有了相當(dāng)程度的改進(jìn),但是信號這種通信方式更像"即時"的通信方式,它要求接受信號的進(jìn)程在某個時間范圍內(nèi)對信號做出反應(yīng),因此該信號最多在接受信號進(jìn)程的生命周期內(nèi)才有意義,信號所傳遞的信息是接近于隨進(jìn)程持續(xù)的概念(process-persistent),見附錄 1;管道及有名管道及有名管道則是典型的隨進(jìn)程持續(xù)IPC,并且,只能傳送無格式的字節(jié)流無疑會給應(yīng)用程序開發(fā)帶來不便,另外,它的緩沖區(qū)大小也受到限制。
消息隊列就是一個消息的鏈表。可以把消息看作一個記錄,具有特定的格式以及特定的優(yōu)先級。對消息隊列有寫權(quán)限的進(jìn)程可以向中按照一定的規(guī)則添加新消息;對消息隊列有讀權(quán)限的進(jìn)程則可以從消息隊列中讀走消息。消息隊列是隨內(nèi)核持續(xù)的(參見附錄 1)。
目前主要有兩種類型的消息隊列:POSIX消息隊列以及系統(tǒng)V消息隊列,系統(tǒng)V消息隊列目前被大量使用。考慮到程序的可移植性,新開發(fā)的應(yīng)用程序應(yīng)盡量使用POSIX消息隊列。
在本系列專題的序(深刻理解Linux進(jìn)程間通信(IPC))中,提到對于消息隊列、信號燈、以及共享內(nèi)存區(qū)來說,有兩個實(shí)現(xiàn)版本:POSIX的以及系統(tǒng)V的。Linux內(nèi)核(內(nèi)核2.4.18)支持POSIX信號燈、POSIX共享內(nèi)存區(qū)以及POSIX消息隊列,但對于主流Linux發(fā)行版本之一redhad8.0(內(nèi)核2.4.18),還沒有提供對POSIX進(jìn)程間通信API的支持,不過應(yīng)該只是時間上的事。
因此,本文將主要介紹系統(tǒng)V消息隊列及其相應(yīng)API。在沒有聲明的情況下,以下討論中指的都是系統(tǒng)V消息隊列。
- 系統(tǒng)V消息隊列是隨內(nèi)核持續(xù)的,只有在內(nèi)核重起或者顯示刪除一個消息隊列時,該消息隊列才會真正被刪除。因此系統(tǒng)中記錄消息隊列的數(shù)據(jù)結(jié)構(gòu)(struct ipc_ids msg_ids)位于內(nèi)核中,系統(tǒng)中的所有消息隊列都可以在結(jié)構(gòu)msg_ids中找到訪問入口。
- 消息隊列就是一個消息的鏈表。每個消息隊列都有一個隊列頭,用結(jié)構(gòu)struct msg_queue來描述(參見附錄 2)。隊列頭中包含了該消息隊列的大量信息,包括消息隊列鍵值、用戶ID、組ID、消息隊列中消息數(shù)目等等,甚至記錄了最近對消息隊列讀寫進(jìn)程的ID。讀者可以訪問這些信息,也可以設(shè)置其中的某些信息。
- 下圖說明了內(nèi)核與消息隊列是怎樣建立起聯(lián)系的:
其中:struct ipc_ids msg_ids是內(nèi)核中記錄消息隊列的全局?jǐn)?shù)據(jù)結(jié)構(gòu);struct msg_queue是每個消息隊列的隊列頭。
從上圖可以看出,全局?jǐn)?shù)據(jù)結(jié)構(gòu) struct ipc_ids msg_ids 可以訪問到每個消息隊列頭的第一個成員:struct kern_ipc_perm;而每個struct kern_ipc_perm能夠與具體的消息隊列對應(yīng)起來是因為在該結(jié)構(gòu)中,有一個key_t類型成員key,而key則唯一確定一個消息隊列。kern_ipc_perm結(jié)構(gòu)如下:
|
對消息隊列的操作無非有下面三種類型:
1、 打開或創(chuàng)建消息隊列
消息隊列的內(nèi)核持續(xù)性要求每個消息隊列都在系統(tǒng)范圍內(nèi)對應(yīng)唯一的鍵值,所以,要獲得一個消息隊列的描述字,只需提供該消息隊列的鍵值即可;
注:消息隊列描述字是由在系統(tǒng)范圍內(nèi)唯一的鍵值生成的,而鍵值可以看作對應(yīng)系統(tǒng)內(nèi)的一條路經(jīng)。
2、 讀寫操作
消息讀寫操作非常簡單,對開發(fā)人員來說,每個消息都類似如下的數(shù)據(jù)結(jié)構(gòu):
|
mtype成員代表消息類型,從消息隊列中讀取消息的一個重要依據(jù)就是消息的類型;mtext是消息內(nèi)容,當(dāng)然長度不一定為1。因此,對于發(fā)送消息來說,首先預(yù)置一個msgbuf緩沖區(qū)并寫入消息類型和內(nèi)容,調(diào)用相應(yīng)的發(fā)送函數(shù)即可;對讀取消息來說,首先分配這樣一個msgbuf緩沖區(qū),然后把消息讀入該緩沖區(qū)即可。
3、 獲得或設(shè)置消息隊列屬性:
消息隊列的信息基本上都保存在消息隊列頭中,因此,可以分配一個類似于消息隊列頭的結(jié)構(gòu)(struct msqid_ds,見附錄 2),來返回消息隊列的屬性;同樣可以設(shè)置該數(shù)據(jù)結(jié)構(gòu)。

消息隊列API
1、文件名到鍵值
|
它返回與路徑pathname相對應(yīng)的一個鍵值。該函數(shù)不直接對消息隊列操作,但在調(diào)用ipc(MSGGET,…)或msgget()來獲得消息隊列描述字前,往往要調(diào)用該函數(shù)。典型的調(diào)用代碼是:
|
2、linux為操作系統(tǒng)V進(jìn)程間通信的三種方式(消息隊列、信號燈、共享內(nèi)存區(qū))提供了一個統(tǒng)一的用戶界面:int ipc(unsigned int call, int first, int second, int third, void *ptr, long fifth);
第一個參數(shù)指明對IPC對象的操作方式,對消息隊列而言共有四種操作:MSGSND、MSGRCV、MSGGET以及MSGCTL,分別代表向消息隊列發(fā)送消息、從消息隊列讀取消息、打開或創(chuàng)建消息隊列、控制消息隊列;first參數(shù)代表唯一的IPC對象;下面將介紹四種操作。
- int ipc(MSGGET, int first, int second, int third, void *ptr, long fifth);
與該操作對應(yīng)的系統(tǒng)V調(diào)用為:int msgget( (key_t)first,second)。 - int ipc(MSGCTL, int first, int second, int third, void *ptr, long fifth)
與該操作對應(yīng)的系統(tǒng)V調(diào)用為:int msgctl( first,second, (struct msqid_ds*) ptr)。 - int ipc(MSGSND, int first, int second, int third, void *ptr, long fifth);
與該操作對應(yīng)的系統(tǒng)V調(diào)用為:int msgsnd( first, (struct msgbuf*)ptr, second, third)。 - int ipc(MSGRCV, int first, int second, int third, void *ptr, long fifth);
與該操作對應(yīng)的系統(tǒng)V調(diào)用為:int msgrcv( first,(struct msgbuf*)ptr, second, fifth,third),
注:本人不主張采用系統(tǒng)調(diào)用ipc(),而更傾向于采用系統(tǒng)V或者POSIX進(jìn)程間通信API。原因如下:
- 雖然該系統(tǒng)調(diào)用提供了統(tǒng)一的用戶界面,但正是由于這個特性,它的參數(shù)幾乎不能給出特定的實(shí)際意義(如以first、second來命名參數(shù)),在一定程度上造成開發(fā)不便。
- 正如ipc手冊所說的:ipc()是linux所特有的,編寫程序時應(yīng)注意程序的移植性問題;
- 該系統(tǒng)調(diào)用的實(shí)現(xiàn)不過是把系統(tǒng)V IPC函數(shù)進(jìn)行了封裝,沒有任何效率上的優(yōu)勢;
- 系統(tǒng)V在IPC方面的API數(shù)量不多,形式也較簡潔。
3.系統(tǒng)V消息隊列API
系統(tǒng)V消息隊列API共有四個,使用時需要包括幾個頭文件:
|
1)int msgget(key_t key, int msgflg)
參數(shù)key是一個鍵值,由ftok獲得;msgflg參數(shù)是一些標(biāo)志位。該調(diào)用返回與健值key相對應(yīng)的消息隊列描述字。
在以下兩種情況下,該調(diào)用將創(chuàng)建一個新的消息隊列:
- 如果沒有消息隊列與健值key相對應(yīng),并且msgflg中包含了IPC_CREAT標(biāo)志位;
- key參數(shù)為IPC_PRIVATE;
參數(shù)msgflg可以為以下:IPC_CREAT、IPC_EXCL、IPC_NOWAIT或三者的或結(jié)果。
調(diào)用返回:成功返回消息隊列描述字,否則返回-1。
注:參數(shù)key設(shè)置成常數(shù)IPC_PRIVATE并不意味著其他進(jìn)程不能訪問該消息隊列,只意味著即將創(chuàng)建新的消息隊列。
2)int msgrcv(int msqid, struct msgbuf *msgp, int msgsz, long msgtyp, int msgflg);
該系統(tǒng)調(diào)用從msgid代表的消息隊列中讀取一個消息,并把消息存儲在msgp指向的msgbuf結(jié)構(gòu)中。
msqid為消息隊列描述字;消息返回后存儲在msgp指向的地址,msgsz指定msgbuf的mtext成員的長度(即消息內(nèi)容的長度),msgtyp為請求讀取的消息類型;讀消息標(biāo)志msgflg可以為以下幾個常值的或:
- IPC_NOWAIT 如果沒有滿足條件的消息,調(diào)用立即返回,此時,errno=ENOMSG
- IPC_EXCEPT 與msgtyp>0配合使用,返回隊列中第一個類型不為msgtyp的消息
- IPC_NOERROR 如果隊列中滿足條件的消息內(nèi)容大于所請求的msgsz字節(jié),則把該消息截斷,截斷部分將丟失。
msgrcv手冊中詳細(xì)給出了消息類型取不同值時(>0; <0; =0),調(diào)用將返回消息隊列中的哪個消息。
msgrcv()解除阻塞的條件有三個:
- 消息隊列中有了滿足條件的消息;
- msqid代表的消息隊列被刪除;
- 調(diào)用msgrcv()的進(jìn)程被信號中斷;
調(diào)用返回:成功返回讀出消息的實(shí)際字節(jié)數(shù),否則返回-1。
3)int msgsnd(int msqid, struct msgbuf *msgp, int msgsz, int msgflg);
向msgid代表的消息隊列發(fā)送一個消息,即將發(fā)送的消息存儲在msgp指向的msgbuf結(jié)構(gòu)中,消息的大小由msgze指定。
對發(fā)送消息來說,有意義的msgflg標(biāo)志為IPC_NOWAIT,指明在消息隊列沒有足夠空間容納要發(fā)送的消息時,msgsnd是否等待。造成msgsnd()等待的條件有兩種:
- 當(dāng)前消息的大小與當(dāng)前消息隊列中的字節(jié)數(shù)之和超過了消息隊列的總?cè)萘浚?
- 當(dāng)前消息隊列的消息數(shù)(單位"個")不小于消息隊列的總?cè)萘浚▎挝?字節(jié)數(shù)"),此時,雖然消息隊列中的消息數(shù)目很多,但基本上都只有一個字節(jié)。
msgsnd()解除阻塞的條件有三個:
- 不滿足上述兩個條件,即消息隊列中有容納該消息的空間;
- msqid代表的消息隊列被刪除;
- 調(diào)用msgsnd()的進(jìn)程被信號中斷;
調(diào)用返回:成功返回0,否則返回-1。
4)int msgctl(int msqid, int cmd, struct msqid_ds *buf);
該系統(tǒng)調(diào)用對由msqid標(biāo)識的消息隊列執(zhí)行cmd操作,共有三種cmd操作:IPC_STAT、IPC_SET 、IPC_RMID。
- IPC_STAT:該命令用來獲取消息隊列信息,返回的信息存貯在buf指向的msqid結(jié)構(gòu)中;
- IPC_SET:該命令用來設(shè)置消息隊列的屬性,要設(shè)置的屬性存儲在buf指向的msqid結(jié)構(gòu)中;可設(shè)置屬性包括:msg_perm.uid、msg_perm.gid、msg_perm.mode以及msg_qbytes,同時,也影響msg_ctime成員。
- IPC_RMID:刪除msqid標(biāo)識的消息隊列;
調(diào)用返回:成功返回0,否則返回-1。
三、消息隊列的限制
每個消息隊列的容量(所能容納的字節(jié)數(shù))都有限制,該值因系統(tǒng)不同而不同。在后面的應(yīng)用實(shí)例中,輸出了redhat 8.0的限制,結(jié)果參見附錄 3。
另一個限制是每個消息隊列所能容納的最大消息數(shù):在redhad 8.0中,該限制是受消息隊列容量制約的:消息個數(shù)要小于消息隊列的容量(字節(jié)數(shù))。
注:上述兩個限制是針對每個消息隊列而言的,系統(tǒng)對消息隊列的限制還有系統(tǒng)范圍內(nèi)的最大消息隊列個數(shù),以及整個系統(tǒng)范圍內(nèi)的最大消息數(shù)。一般來說,實(shí)際開發(fā)過程中不會超過這個限制。
四、消息隊列應(yīng)用實(shí)例
消息隊列應(yīng)用相對較簡單,下面實(shí)例基本上覆蓋了對消息隊列的所有操作,同時,程序輸出結(jié)果有助于加深對前面所講的某些規(guī)則及消息隊列限制的理解。
|
小結(jié):
消息隊列與管道以及有名管道相比,具有更大的靈活性,首先,它提供有格式字節(jié)流,有利于減少開發(fā)人員的工作量;其次,消息具有類型,在實(shí)際應(yīng)用中,可作為優(yōu)先級使用。這兩點(diǎn)是管道以及有名管道所不能比的。同樣,消息隊列可以在幾個進(jìn)程間復(fù)用,而不管這幾個進(jìn)程是否具有親緣關(guān)系,這一點(diǎn)與有名管道很相似;但消息隊列是隨內(nèi)核持續(xù)的,與有名管道(隨進(jìn)程持續(xù))相比,生命力更強(qiáng),應(yīng)用空間更大。
附錄 1:在參考文獻(xiàn)[1]中,給出了IPC隨進(jìn)程持續(xù)、隨內(nèi)核持續(xù)以及隨文件系統(tǒng)持續(xù)的定義:
- 隨進(jìn)程持續(xù):IPC一直存在到打開IPC對象的最后一個進(jìn)程關(guān)閉該對象為止。如管道和有名管道;
- 隨內(nèi)核持續(xù):IPC一直持續(xù)到內(nèi)核重新自舉或者顯示刪除該對象為止。如消息隊列、信號燈以及共享內(nèi)存等;
- 隨文件系統(tǒng)持續(xù):IPC一直持續(xù)到顯示刪除該對象為止。
附錄 2:
結(jié)構(gòu)msg_queue用來描述消息隊列頭,存在于系統(tǒng)空間:
|
結(jié)構(gòu)msqid_ds用來設(shè)置或返回消息隊列的信息,存在于用戶空間;
|
附錄 3:消息隊列實(shí)例輸出結(jié)果:
|
- UNIX網(wǎng)絡(luò)編程第二卷:進(jìn)程間通信,作者:W.Richard Stevens,譯者:楊繼張,清華大學(xué)出版社。對POSIX以及系統(tǒng)V消息隊列都有闡述,對Linux環(huán)境下的程序開發(fā)有極大的啟發(fā)意義。
- linux內(nèi)核源代碼情景分析(上),毛德操、胡希明著,浙江大學(xué)出版社,給出了系統(tǒng)V消息隊列相關(guān)的源代碼分析。
- http://www.fanqiang.com/a4/b2/20010508/113315.html,主要闡述linux下對文件的操作,詳細(xì)介紹了對文件的存取權(quán)限位,對IPC對象的存取權(quán)限同樣具有很好的借鑒意義。
- msgget、msgsnd、msgrcv、msgctl手冊
關(guān)于作者: 鄭彥興,國防科大攻讀博士學(xué)位。聯(lián)系方式: mlinux@163.com |
posted on 2005-08-04 13:04 weidagang2046 閱讀(344) 評論(0) 編輯 收藏 所屬分類: Linux