进程间的通信——消息队列篇

进程间的通信——共享内存https://blog.csdn.net/q496958148/article/details/79953349
进程间的通信——信号量https://blog.csdn.net/q496958148/article/details/79977093
进程间的通信——管 道https://blog.csdn.net/q496958148/article/etails/79948367

什么是消息队列？

消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。也就是说进程的退出，如果不自主去释放资源，消息队列是会悄无声息的存在的。消息队列与管道不同的是，消息队列是基于消息的， 而管道是基于字节流的，且消息队列的读取不一定是先入先出。消息队列与命名管道有一 样的不足，就是每个消息的最大长度是有上限的（MSGMAX），每个消息队列的总的字节数是有上限的（MSGMNB），系统上消息队列的总数也有一个上限

进程通信我们有了管道，为什么还要引入消息队列呢？

因为根据管道的特性，我们知道其在一定程度上存在或多或少的局限性，首先匿名管道以及命名管道是随进程的，进程的退出，意味着管道生命周期的结束；其次，管道传送数据时以无格式字节流的形式传送，这有时会给程序的开发带来不便；再者，担当数据传送媒介的管道，其缓冲区的大小也有较大的限制。所以作为IPC方式下的另一种应用于进程间通信的消息队列方式便应运而生了。
IPC对象数据结构:

//内核为每个IPC对象维护了一个数据结构
struct ipc_perm
{
    __kernel_key_t  key;//key值是消息队列的一个验证码（我理解为暗号，首先一个进程要向消息队列放入一个东西，得先生成一个key值，这个key值是函数计算得来的，输入值确定会固定得到一个key值，而又有一个进程需要取刚才进程放的东西，这时候就得暗号匹配才能取。）
    __kernel_uid_t  uid;
    __kernel_gid_t  gid;
    __kernel_uid_t  cuid;
    __kernel_gid_t  cgid;
    __kernel_mode_t mode; //权限
    unsigned short  seq;
};

消息队列结构：

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</