Linux進程間通信之消息隊列(轉)

原文地址: http://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消息隊列。

一、消息隊列基本概念

系統V消息隊列是隨內核持續的，只有在內核重起或者顯示刪除一個消息隊列時，該消息隊列纔會真正被刪除。因此係統中記錄消息隊列的數據結構（struct ipc_ids msg_ids）位於內核中，系統中的所有消息隊列都可以在結構msg_ids中找到訪問入口。
消息隊列就是一個消息的鏈表。每個消息隊列都有一個隊列頭，用結構struct msg_queue來描述（參見附錄 2）。隊列頭中包含了該消息隊列的大量信息，包括消息隊列鍵值、用戶ID、組ID、消息隊列中消息數目等等，甚至記錄了最近對消息隊列讀寫進程的ID。讀者可以訪問這些信息，也可以設置其中的某些信息。
下圖說明了內核與消息隊列是怎樣建立起聯繫的：
其中：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;
}

回頁首

二、操作消息隊列

對消息隊列的操作無非有下面三種類型：

1、打開或創建消息隊列
消息隊列的內核持續性要求每個消息隊列都在系統範圍內對應唯一的鍵值，所以，要獲得一個消息隊列的描述字，只需提供該消息隊列的鍵值即可；

注：消息隊列描述字是由在系統範圍內唯一的鍵值生成的，而鍵值可以看作對應系統內的一條路經。

2、讀寫操作

消息讀寫操作非常簡單，對開發人員來說，每個消息都類似如下的數據結構：

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

mtype成員代表消息類型，從消息隊列中讀取消息的一個重要依據就是消息的類型；mtext是消息內容，當然長度不一定爲1。因此，對於發送消息來說，首先預置一個msgbuf緩衝區並寫入消息類型和內容，調用相應的發送函數即可；對讀取消息來說，首先分配這樣一個msgbuf緩衝區，然後把消息讀入該緩衝區即可。

3、獲得或設置消息隊列屬性：

消息隊列的信息基本上都保存在消息隊列頭中，因此，可以分配一個類似於消息隊列頭的結構(struct msqid_ds，見附錄 2)，來返回消息隊列的屬性；同樣可以設置該數據結構。

消息隊列API

1、文件名到鍵值

#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);
    …

2、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()解除阻塞的條件有三個：

消息隊列中有了滿足條件的消息；
msqid代表的消息隊列被刪除；
調用msgrcv（）的進程被信號中斷；

調用返回：成功返回讀出消息的實際字節數，否則返回-1。

3）int msgsnd(int msqid, struct msgbuf *msgp, int msgsz, int msgflg);
向msgid代表的消息隊列發送一個消息，即將發送的消息存儲在msgp指向的msgbuf結構中，消息的大小由msgze指定。

對發送消息來說，有意義的msgflg標誌爲IPC_NOWAIT，指明在消息隊列沒有足夠空間容納要發送的消息時，msgsnd是否等待。造成msgsnd()等待的條件有兩種：

當前消息的大小與當前消息隊列中的字節數之和超過了消息隊列的總容量；
當前消息隊列的消息數（單位"個"）不小於消息隊列的總容量（單位"字節數"），此時，雖然消息隊列中的消息數目很多，但基本上都只有一個字節。

msgsnd()解除阻塞的條件有三個：

不滿足上述兩個條件，即消息隊列中有容納該消息的空間；
msqid代表的消息隊列被刪除；
調用msgsnd（）的進程被信號中斷；

調用返回：成功返回0，否則返回-1。

4）int msgctl(int msqid, int cmd, struct msqid_ds *buf);
該系統調用對由msqid標識的消息隊列執行cmd操作，共有三種cmd操作：IPC_STAT、IPC_SET 、IPC_RMID。

IPC_STAT：該命令用來獲取消息隊列信息，返回的信息存貯在buf指向的msqid結構中；
IPC_SET：該命令用來設置消息隊列的屬性，要設置的屬性存儲在buf指向的msqid結構中；可設置屬性包括：msg_perm.uid、msg_perm.gid、msg_perm.mode以及msg_qbytes，同時，也影響msg_ctime成員。
IPC_RMID：刪除msqid標識的消息隊列；

調用返回：成功返回0，否則返回-1。

回頁首

三、消息隊列的限制

每個消息隊列的容量（所能容納的字節數）都有限制，該值因系統不同而不同。在後面的應用實例中，輸出了redhat 8.0的限制，結果參見附錄 3。

另一個限制是每個消息隊列所能容納的最大消息數：在redhad 8.0中，該限制是受消息隊列容量制約的：消息個數要小於消息隊列的容量（字節數）。

注：上述兩個限制是針對每個消息隊列而言的，系統對消息隊列的限制還有系統範圍內的最大消息隊列個數，以及整個系統範圍內的最大消息數。一般來說，實際開發過程中不會超過這個限制。

回頁首

四、消息隊列應用實例

這個程序用來創建消息隊列, 併發送3條消息給消息隊列

#include <sys/types.h>
#include <sys/msg.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <error.h>

#define BUF_SIZE 20

/* 定義message buf, mtype必須在mtext前面 */
struct msgbuf {
    long mtype;
    char mtext[BUF_SIZE];
};

int main()
{
    struct msgbuf sendbuf;
    struct msqid_ds msg_info;
    int msgid;

    /* 隊列key爲0x33, 沒有的話, 自動創建 */
    if ((msgid = msgget(0x33, IPC_CREAT | 0600)) == -1) {
        perror("msgget");
        exit(0);
    }
    printf("msgid = %d\n", msgid);

    sendbuf.mtype = 666;
    sprintf(sendbuf.mtext, "%s", "foo");
    if (msgsnd(msgid, &sendbuf, BUF_SIZE, IPC_NOWAIT) == -1) {
        perror("msgsnd");
    }

    sendbuf.mtype = 777;
    sprintf(sendbuf.mtext, "%s", "bar");
    if (msgsnd(msgid, &sendbuf, BUF_SIZE, IPC_NOWAIT) == -1) {
        perror("msgsnd");
    }

    sendbuf.mtype = 666;
    sprintf(sendbuf.mtext, "%s", "foobar");
    if (msgsnd(msgid, &sendbuf, BUF_SIZE, IPC_NOWAIT) == -1) {
        perror("msgsnd");
    }

    if (msgctl(msgid, IPC_STAT, &msg_info) == -1) {
        perror("msgctl");
    }
    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);

    return 0;
}

運行結果如下:

msgid = 425984
current number of bytes on queue is 60
number of messages in queue is 3

再來一個程序, 從消息隊列中讀取數據

#include <sys/types.h>
#include <sys/msg.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define BUF_SIZE 20

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

int main()
{
    struct msgbuf recvbuf;
    struct msqid_ds msg_info;
    int msgid;
    long msg_to_receive;

    if ((msgid = msgget(0x33, IPC_CREAT | 0600)) == -1) {
        perror("msgget");
        exit(0);
    }
    
    if (msgctl(msgid, IPC_STAT, &msg_info) == -1) {
        perror("msgctl");
    }
    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);

    msg_to_receive = 777;
    if (msgrcv(msgid, &recvbuf, BUF_SIZE, msg_to_receive, IPC_NOWAIT) == -1) {
        perror("msgrcv");
    }
    printf("%ld\n", recvbuf.mtype);
    printf("%s\n", recvbuf.mtext);

    msg_to_receive = 0;
    if (msgrcv(msgid, &recvbuf, BUF_SIZE, msg_to_receive, IPC_NOWAIT) == -1) {
        perror("msgrcv");
    }
    printf("%ld\n", recvbuf.mtype);
    printf("%s\n", recvbuf.mtext);

    msg_to_receive = 666;
    if (msgrcv(msgid, &recvbuf, BUF_SIZE, msg_to_receive, IPC_NOWAIT) == -1) {
        perror("msgrcv");
    }
    printf("%ld\n", recvbuf.mtype);
    printf("%s\n", recvbuf.mtext);
}

運行結果如下:

current number of bytes on queue is 60
number of messages in queue is 3
777
bar
666
foo
666
foobar

小結：

消息隊列與管道以及有名管道相比，具有更大的靈活性，首先，它提供有格式字節流，有利於減少開發人員的工作量；其次，消息具有類型，在實際應用中，可作爲優先級使用。這兩點是管道以及有名管道所不能比的。同樣，消息隊列可以在幾個進程間複用，而不管這幾個進程是否具有親緣關係，這一點與有名管道很相似；但消息隊列是隨內核持續的，與有名管道（隨進程持續）相比，生命力更強，應用空間更大。

附錄 1： 在參考文獻[1]中，給出了IPC隨進程持續、隨內核持續以及隨文件系統持續的定義：

隨進程持續：IPC一直存在到打開IPC對象的最後一個進程關閉該對象爲止。如管道和有名管道；
隨內核持續：IPC一直持續到內核重新自舉或者顯示刪除該對象爲止。如消息隊列、信號燈以及共享內存等；
隨文件系統持續：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 */
};

//可以看出上述兩個結構很相似.

個人總結:

1. 信號和管道都是隨進程持續的, 並且只能傳送無格式的字節流, 而消息隊列是隨內核持續的. 即只有在內核重起或者顯

示刪除一個消息隊列時，該消息隊列纔會真正被刪除。而且, 消息隊列提供有格式字節流, 有助於減少開發人員的工作量.

2. 消息隊列, 共享內存和信號量都是隨內核持續的, 命令 ipcs 可以查看當前系統存在的ipc. 命令 ipcrm 可以刪除某個ipc

3. 消息具有類型，在實際應用中，可作爲優先級使用。有了類型, 不同類型的數據可能不會保證先進先出.但同一類型的數據可以保證先進先出

4. 理解消息隊列的內核實現

iteye_3185

發佈了29 篇原創文章 · 獲贊 4 · 訪問量 7448

私信關注

Linux進程間通信之消息隊列(轉)

再談23種設計模式（3）：行爲型模式（學習筆記）

Power Automate Desktop 安裝完，登錄後老是提示one driver 錯誤

微前端學習筆記(4):從微前端到微模塊之EMP與hel-micro方案探索

微前端學習筆記（1）：微前端總體架構概述，從微服務發微

985 碩士程序員，空窗 4 個月沒有 Offer！

一文搞懂 Spring 循環依賴

賽博鬥地主——使用大語言模型扮演Agent智能體玩牌類遊戲。

VScode右鍵打開(添加到右鍵)

記一次 .NET某工控視覺自動化系統卡死分析

WindowsServer--SQL Server搭建主從同步實現讀寫分離 - 事務性分發

Erlang 學習筆記

nginx源碼閱讀筆記

Linux進程通信之管道

Memcached內存管理機制

Linux進程間通信之消息隊列(轉)

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

Linux進程間通信 之 消息隊列(轉)

Linux進程間通信之消息隊列(轉)