《Linux原理与结构》课件第10章

第十章进 程 间 通 信10.1信号10.2管道10.3消息队列10.4共享内存利用锁、信号量、RCU等可以协调进程的动作，实现进程间的互斥与同步，但所传递的信息量极少，难以用于进程间通信。为了使相互协作的进程能够更好地工作，除了互斥与同步之外，还需要提供一些进程间的通信机制，如通知机制、信息传递机制、信息共享机制等。

早期的Unix仅提供了两种进程间通信机制，分别是用于通知的信号和用于传递数据的管道。1983年，AT&T在UnixSystemV中引入了三种新的进程间通信机制，分别是信息队列、共享内存和信号量集合。在随后的发展中，SystemV的三种通信机制被吸收进POSIX标准，但两者使用了完全不同的API，因而具有完全不同的实现方式。

Linux继承了Unix的传统，提供了多种进程间的通信机制，如用于通知的信号，用于交换信息的管道和消息队列，用于共享信息的共享内存等。在所有的通信手段中，信号是最基本的，管道与消息队列是最直观的，共享内存是最快速的。当然，通过网络协议既可实现不同计算机间的进程通信，也可实现同一计算机内部的进程通信。事实上，网络协议是一种最复杂的进程间通信机制。

信号(Signal)是用于通知事件的一种机制。当内核有事情需要通知进程时，它可以发送信号。当一个进程有事情需要通知另一个进程时，它也可以发送信号。信号还是一种原始的进程间同步机制，一个进程可以暂停工作等待被其它进程的信号唤醒。与其它通信机制不同，信号是Linux必备的一种通信机制，是Linux内核不可分割的一部分。10.1信号最早的信号机制是由UnixSystemV引入的。BSD4.2解决了信号中的许多问题，BSD4.3又对其做了进一步的加强和改善。POSIX.1定义了一个标准的信号接口，POSIX.4又对其进行了扩充。目前几乎所有的Unix变种，包括Linux，都提供了和POSIX标准兼容的信号机制。10.1.1信号定义

信号的格式和意义都是预先约定好的，一个信号表示一种类型的事件。能产生信号的实体称为信号源，主要的信号源是内核和进程。内核通过信号将系统内发生的事件通知进程，如进程执行了非法操作、进程使用的资源超限、用户输入了Ctrl-C、进程启动的定时器已到期等。一个进程也可以向另一个或一组进程发送信号，用来通知事件、控制作业等，如通过向一个进程发送SIGKILL信号来将其杀死等。

Unix通常用一个无符号长整数作为位图来表示信号，其中的一位对应一种信号。Linux用一个整数数组作为位图来表示信号，数量可以更多。缺省情况下，Linux支持的信号有64个，其中1到31为普通信号，32到63为实时信号，第0个信号保留未用。普通信号的意义是固定的，实时信号的意义由用户自定义，且可传递附加信息。表10.1是Linux的普通信号。

表10.1普通信号及其意义Linux系统中的每个进程都可能收到信号，而且可以用不同的方式处理信号。进程对信号的处理方式有下列几种：

(1)阻塞。将到来的信号记录下来但不处理，直到阻塞被解除。

(2)忽略(SIG_IGN)。不接收或不处理信号，直接将其丢弃。

(3)缺省(SIG_DFL)。由内核按缺省方式处理信号。

(4)自定义。由进程自己注册的用户态信号处理程序处理信号。

Linux内核提供了五种缺省的信号处理方式，分别是：

(1)夭折(abort)。把进程虚拟地址空间中的内容存入文件core后终止进程。

(2)终止(exit)。直接终止进程，不生成core文件。

(3)忽略(ignore)。忽略或丢弃收到的信号。

(4)停止(stop)。让进程停止运行。

(5)继续(continue)。如果进程已被停止，则让其恢复运行；否则忽略信号。

信号必须由接收者进程自己处理，处理方法由接收者进程自己决定。如果信号的接收者当前未在运行态，那么它对信号的处理就不会很及时。

另外，信号没有优先级，信号处理的先后顺序完全取决于系统的设计。信号可能被接收者忽略或阻塞，因而接收者可能感觉不到某些信号的到来，也就是说信号可能会丢失。

10.1.2信号管理结构

在早期的版本中，Linux用定义在task_struct结构中的位图signal记录进程已收到且未处理的信号，用位图blocked记录进程当前要阻塞的信号，用sigqueue结构队列记录信号的附加信息。当位图signal&(～blocked)不空时，说明进程收到了未被阻塞的信号，应该在适当的时机执行一下这些信号的处理程序。进程预定的信号处理程序记录在它的signal_struct结构中，其主要内容是一个数组，每一种信号对应其中的一项，用于记录进程预定的信号处理程序及处理信号时的特殊要求。老的信号管理结构十分直观，但未照顾到线程组的特殊需求。事实上，线程组中的进程可以作为个体接收信号，也可以作为整体接收信号。作为个体接收的信号只需自己处理即可，但作为整体接收的信号却可被线程组中的任一进程处理。为了区分整体与个体信号，新版本的Linux保留了task_struct结构中的blocked位图，但却将signal位图与信号队列合并到了sigpending结构中。进程作为个体所收到的信号记录在task_struct结构的pending队列中，作为整体所收到的信号记录在signal_struct结构的shared_pending队列中，一个线程组中的所有进程共享同一个signal_struct结构。进程预定的信号处理方式被从结构signal_struct中分离出来，形成了独立的sighand_struct结构，其主要内容是一个action数组(数组长度为64)，记录着进程对各信号的处理程序及处理时的特殊要求。新版本的信号管理结构如图10.1所示。

图10.1进程的信号管理结构注意，信号是从1开始编码的，信号i(i>0)对应位图blocked和signal的第i-1位。

由于signal_struct结构是线程组中所有进程共享的，因而除了可用它记录收到的信号之外，还可在其中记录一些组内进程共享的其它信息，如：

(1)线程组的各类统计信息，包括：

①累计消耗的用户态时间、核心态时间等。

②进程运行的实际总时间。

③累计产生的主(需读磁盘)、次(不需读磁盘)页故障异常的次数。④驻留在内存中的最大页数。

⑤累计产生的输入输出量，如读入的字节数、写出的字节数、读操作的次数、写操作的次数等。

(2)线程组能够使用的各类资源的上界，包括可消耗的处理器时间、可使用的优先级、可创建文件的大小、可使用数据区的大小、可使用堆栈区的大小、可驻留内存的页数、可创建的进程数、可打开的文件数、可挂起的信号数、可挂起的消息长度等。

(3)三类时间间隔定时器的管理信息，包括用于实时定时的高精度定时器、三类间隔定时器的定时间隔、虚拟和概略定时器的当前值等。

(4)与线程组关联的终端。

(5)用于等待子进程终止的进程等待队列等。

10.1.3信号处理程序注册

每个进程的task_struct结构中都有一个指向sighand_struct结构的指针，其中记录着进程对各种信号的处理方式，主要是各种信号的处理程序。当然，多个进程(如同一线程组中的进程)可以共用一个sighand_struct结构。结构sighand_struct的定义如下：

structsigaction{

_sighandler_t sa_handler; //信号处理程序

unsignedlong sa_flags; //信号的特殊处理需求

_sigrestore_t sa_restorer; //善后处理程序

sigset_t sa_mask; //处理信号时的新增阻塞位

};

structk_sigaction{

structsigaction sa;

};

structsighand_struct{

atomic_t count; //引用计数

structk_sigaction action[_NSIG]; //信号处理程序列表，_NSIG等于64

spinlock_t siglock; //保护用自旋锁

wait_queue_head_t signalfd_wqh; //等待接收该信号的进程队列

};第0号进程的sighand_struct结构是静态建立的，它的所有信号处理程序都是缺省(SIG_DFL)的。其它进程的sighand_struct结构都是动态建立的。在创建之初，进程要么与创建者共用同一个sighand_struct结构，要么从创建者复制一个sighand_struct结构，因而在创建之初，进程处理信号的方式与创建者进程完全相同。在为进程加载新的执行程序之前，加载程序会为进程建立独立的sighand_struct结构，并对其进行清理。在清理后的sighand_struct结构中，用户自定义的所有处理程序都被换成了缺省的SIG_DFL，所有的sa_mask和sa_flags也都被清空。

运行中的进程可以通过系统调用(如signal()、sigaction()、rt_sigaction()等)更改自己对各信号的处理方式，包括注册自己定义的信号处理程序。函数signal()是较老的一个系统调用(即将被淘汰)，仅能设置信号处理程序。函数sigaction()可以设置一个信号的处理程序及阻塞掩码、特殊标志等，但由于结构的变化，也将被淘汰。函数rt_sigaction()是目前建议的系统调用，可用于设置一个信号处理的所有部分。进程设置的信号处理程序可以是缺省(SIG_DFL)、忽略(SIG_IGN)或自定义的函数。如果进程设置的信号处理程序是一个自定义的用户空间函数，那么sigaction结构中的sa_handler将指向该函数。如果进程将某信号的处理程序换成了忽略，那么它此前收到的该种信号会被清除。由于信号SIGCONT、SIGCHLD、SIGWINCH和SIGURG的缺省处理是忽略，因而若进程将这四个信号的处理程序换成了缺省，那么它此前收到的这些信号也会被清除。

SIGKILL和SIGSTOP是内核专用的信号，它们的处理方式不能被更改。

系统调用sigprocmask()专门用于设置或获取进程的阻塞掩码blocked。10.1.4信号发送

与其它形式的通信机制不同，信号是由发送者直接送给接收者的，接收者不需要采取任何接收动作。也就是说，信号的发送和接收都是由发送者进程负责的，操作系统只需要提供信号的发送操作即可。发送信号的进程必须在运行状态，但接收信号的进程却可以在任意状态。处于可中断等待状态或停止状态的进程可能会被收到的信号唤醒。

在早期的Unix系统中，发送信号实际就是在接收者进程的signal位图中设置一个标志。信号的接收者只知道收到了某类信号，却不知道信号的来源和数量。在Linux的早期实现中，实时信号可以带一个附加信息，这些附加信息被挂在接收者进程的信号队列中，因而实时信号有了数量的概念。新版本的Linux给普通信号也准备了附加信息，可用于通报信号的来源，但为了与老版本兼容，普通信号仍没有数量的概念。

信号的附加信息被包装在结构sigqueue中，其中内嵌的结构siginfo用于描述附加信息本身，主要内容如下：

(1)域si_signo中记录着信号的编码，从1开始。

(2)域si_code中记录着信号的来源，如内核、用户、定时器等。

(3)联合_sifields中记录着各信号特定的附加信息，如发送者的pid、uid等。

信号的接收者可以是一个特定的进程，也可以是一个线程组。作为线程组所收到的信号可以被组中的所有进程看到，也可以被组中的任意一个进程处理，但只能被处理一次。不管被哪个进程处理，作为线程组收到的信号都会影响到组中所有的进程。

发送信号的进程至少需要提供四个参数，分别是信号编号、附加信息、接收者进程、目标类别(线程组或单个进程)等。发送信号时完成的工作主要有如下几件：

(1)解决停止与继续信号的矛盾问题，防止它们在接收者进程中共存。①如果要发送的是停止信号(SIGSTOP、SIGTSTP、SIGTTOU、SIGTTIN)，则应将接收者及其线程组此前已收到的继续信号全部清除。

②如果要发送的是继续信号(SIGCONT)，则应将接收者及其线程组此前已收到的停止信号全部清除，并唤醒接收者线程组中所有停止态的进程。

(2)丢弃接收者进程要忽略的信号。在接收者进程中，处理程序为SIG_IGN的信号是被忽略的，处理程序为SIG_DFL的SIGCHLD、SIGCONT、SIGURG或SIGWINCH信号也是被忽略的。接收者进程当前阻塞的信号不能被忽略。

(3)确定新信号将要进驻的接收队列。一个信号只能被加入到一个队列中，信号所在队列由参数中的目标类别决定，可能是task_struct结构中的pending或signal_struct结构中的shared_pending队列。

(4)丢弃重复收到的普通信号。根据传统的信号语义，不需要记录普通信号的接收次数。因而，如果要发送的普通信号已在选定的接收队列中，可将其直接丢弃。

(5)发送信号。

①向对象内存管理器申请一个空闲的sigqueue结构，用发送者提供的参数填写该结构，并将其挂在接收队列的队尾。为了防止拒绝服务类攻击，Linux限制了一个进程可用的sigqueue结构数。②如果有等待该信号的进程(signalfd_wqh队列不空)，则将其中的一个唤醒。

③将信号在队列位图signal中的标志位置1，表示收到了该信号。

(6)善后处理。

①如果接收者是单个进程，在下列情况下，不需要特别的善后处理：

●信号正被接收者阻塞。

●接收者进程正处于停止状态。

●接收者进程当前未在处理器上运行且其上已有待处理的信号。②如果接收者是一个线程组，则在其中选一个满足下列条件之一的进程用来处理该

信号：

●未阻塞该信号且正在运行的进程。

●未阻塞该信号、不在停止状态且无其它待处理信号的进程。

如果组中的所有进程都不能满足上述条件，则不需特别处理。③如果信号(包括SIGKILL)对接收者是致命的(处理动作是终止进程)，则向线程组中的所有进程发送SIGKILL信号，并将处于可中断等待状态或醒后终止状态的进程全部唤醒，以便让它们尽快终止。

④如果信号对接收者不是致命的但为其选定的处理者进程处于可中断等待状态，则将其唤醒。

大部分信号都是由内核发送给进程或线程组的，只有一小部分信号是在进程之间互相发送的。系统会对进程之间互相发送的信号进行严格的权限检查。Linux提供了多个系统调用以便于在进程之间互发信号，主要有以下几个：

(1)函数kill()。在未引入线程组时，该函数用于向一个进程或进程组发送信号。在引入线程组之后，该函数的意义取决于接收者进程的pid：

①

pid>0，用于向一个线程组发送信号，pid是接收者线程组的ID号。

②

pid=0，用于向发送者进程所在的线程组发送信号。

③

pid=-1，用于向当前线程组之外的所有其它线程组发送信号。

④

pid<-1，用于向进程组中的所有进程发送信号，-pid是进程组的ID号。

(2)函数tgkill()用于向一个特定的进程(由TGID和PID标识)发送信号。

(3)函数tkill()是tgkill()的特例，仅指定了PID而未指定TGID，接收者进程可位于任意一个线程组中。

(4)函数rt_sigqueueinfo()用于向一个线程组发送一个带附加信息的信号。

(5)函数rt_tgsigqueueinfo()用于向一个特定的进程发送一个带附加信息的信号。10.1.5信号处理

进程可以在任何状态下接收信号，但只能在从核心态返回用户态之前处理信号，见图4.3。也就是说，信号是由接收者进程在特定时刻自己处理的，有可能不够及时。由于内核守护线程不会返回用户态，因而它们不会处理信号。

进程先处理发给自己的信号(在task_struct结构的pending队列中)，再处理发给线程组的信号(在signal_struct结构的shared_pending队列中)。但进程并不按到达的顺序处理信号。一般情况下，进程会按编号从小到大的顺序处理队列中未被阻塞的信号。然而有些信号是由进程在执行过程中的异常操作引起的，属于同步信号，如SIGSEGV、SIGBUS、SIGILL、SIGTRAP、SIGFPE等，应该优先处理。对同一种信号来说，先收到的先被处理。处理过的信号会被从队列中摘除。当队列中的一种信号被彻底处理完之后，它在位图signal中的标志也会被清除。

进程处理信号的方法由它的sighand_struct结构决定。如果信号的处理程序是忽略(SIG_IGN)，那么简单地将其丢弃即可。如果信号的处理程序是缺省(SIG_DFL)，那么由内核处理即可。内核对不同信号的缺省处理方法也不同，大致可分为如下几类：

(1)忽略。信号SIGCONT、SIGCHLD、SIGWINCH和SIGURG的缺省处理动作是忽略，即将信号直接丢弃。

(2)停止。信号SIGSTOP、SIGTSTP、SIGTTIN和SIGTTOU的缺省处理动作是停止，即将进程所在线程组中的所有进程(包括自己)都设为停止状态。

(3)终止。其它信号的缺省处理动作都是终止，即终止进程所在线程组中的所有进程(包括自己)。终止线程组中其它进程的方法是向它们发送SIGKILL信号，终止自己的方法是执行函数exit()。如果信号的处理程序是用户自定义的，则需要进入用户空间执行一次这一用户态处理程序。由于进程还未返回到用户空间，按照Intel处理器的约定，不能从高特权级向低特权级转移控制，因而不能直接调用处理程序。但由于进程正处在返回用户空间的过程中，其返回状态，包括用户堆栈的栈顶、用户空间下一条指令的地址等，都已记录在进程的系统堆栈中(由pt_regs结构描述，见图4.2)，因而只要将pt_regs结构中的ip换成信号处理程序的入口地址(sighand_struct结构中的sa_handler)，而后让进程正常返回，它就会立刻转去执行自己定义的信号处理程序。然而，对ip域的简单修改破坏了进程的原有返回状态，使得进程在执行完信号处理程序之后无法再返回它在用户空间的应有位置。因而，Linux将自定义信号处理程序的执行过程分成了如下六步：

(1)将系统堆栈栈顶的pt_regs结构暂存起来。

(2)修改进程的用户堆栈，在其中压入必须的参数，如信号编号、附加信息等。

(3)将pt_regs结构中的ip改为自定义信号处理程序的入口地址。

(4)返回用户态，让进程执行自定义的信号处理程序。

(5)在完成处理工作之后，让信号处理程序通过系统调用再次进入内核。

(6)在内核中将进程的系统堆栈恢复到修改之前的状态，而后让进程再次返回。

可以将进程系统堆栈栈顶的pt_regs结构暂存在内核中，也可以将其暂存在用户堆栈中。按照Intel处理器的约定，内核程序可以修改用户空间的数据，因而可以修改用户堆栈。Linux将进程的pt_regs结构暂存在用户堆栈中。

较困难的是让信号处理程序在完成工作之后再次进入内核。强行要求信号处理程序调用一个特定的函数不是一个好办法，因为这会引起程序员的反感，万一遗忘还会导致严重的进程错误。一种解决办法是在用户堆栈的栈顶压入一段善后程序，并通过修改用户堆栈将信号处理程序的返回地址改成善后程序的入口，由这段善后程序负责执行系统调用，以再次进入内核。Linux压到用户堆栈中的善后程序由三条指令组成，如下：

popl％eax //弹出栈顶的参数

movl$_NR_sigreturn,％eax //将系统调用号存入EAX寄存器中

int$0x80 //再次进入内核，执行恢复程序sys_sigreturn()

然而，在堆栈中压入代码是一种非正常的程序执行手段。当堆栈页被禁止执行时(如Intel64中的NXB被置1)，这种手段将无法使用。因而，新版本的Linux将上述善后程序移到了vsyscall页(见4.4.4节)中。由于vsyscall页总在进程的虚拟地址空间中，且以共享库(linux-gate.so)的面目出现，对它的调用总是可行的。既然可以通过修改用户堆栈让信号处理程序返回到预定的善后程序，当然也可以让它返回到正常的返回地址。但由于在执行信号处理程序之前需要修改进程的阻塞掩码blocked(阻塞不希望收到的新信号)，因而在执行完信号处理程序之后还应恢复阻塞掩码。阻塞掩码的修改必须在内核中进行，所以再次进入内核是必须的。

由此可见，执行自定义信号处理程序需要使用到用户堆栈。如果进程的用户堆栈出现了问题(如堆栈溢出)，上述处理方法必将无法工作。为此，Linux允许进程通过系统调用sigaltstack()定义自己的替换堆栈，专门用于执行用户自定义的信号处理程序。替换堆栈的位置记录在task_struct中，开始位置为sas_ss_sp，大小为sas_ss_size。

为了操作方便，Linux将用户堆栈(或替换堆栈)的栈顶定义成了一个结构，称为rt_sigframe，如图10.2所示。

进程系统堆栈的栈顶(pt_regs结构)被保存在用户堆栈的uc_mcontext域中，阻塞掩码被保存在用户堆栈的uc_sigmask域中。信号处理程序的返回地址被保存在pretcode域中，通常就是vsyscall页中的善后程序入口地址。信号的附加信息被压入用户堆栈的栈顶(info域)。Linux内核通过寄存器向信号处理程序传递参数，包括EAX中的信号编号、EDX中的附加信息(info域的地址)、ECX中的ucontext结构等。

进程的新阻塞掩码是老阻塞掩码与位图sa_mask的按位或，有时还需要加上当前处理的信号。如此以来，在信号处理程序的执行过程中，虽然进程可以被中断，可以收到新的信号，但不会被不希望见到的信号打扰。图10.2用户堆栈和系统堆栈的栈顶结构经过上述修改之后，返回到用户态的进程会自然转入自定义的信号处理程序，且可看到需要的参数。当信号处理程序执行完后，最后一条ret指令会将控制转移到vsyscall页中的善后程序。善后程序通过int$0x80再次进入内核，转去执行函数sys_rt_sigreturn()。

函数sys_rt_sigreturn()用保存在用户堆栈中的信息恢复进程的blocked位图和系统堆栈。恢复之后，进程系统堆栈中的sp又指向了用户堆栈的老栈顶(相当于弹出了栈顶的rt_sigframe结构)，ip又指向了正常的返回地址。当函数sys_rt_sigreturn()执行完毕之后，进程又一次从核心态返回用户态，会再次检查进程上是否有待处理的信号。如果还有待处理的信号，进程会继续处理它们。特别地，若信号的处理程序仍然是用户自定义的，系统会再次修改进程的用户堆栈、系统堆栈，再次进入用户空间执行自定义信号处理程序，并在处理完后再次进入内核完成清理工作。

如果进程上已没有待处理的信号，则进程会返回到正常的用户态，从此前被中断的位置恢复正常运行。整个信号处理过程附着在中断处理之后，相当于前一次中断处理或系统调用的延续。

如果进程在执行自定义信号处理程序的过程中再次进入内核(如执行系统调用或被中断)，那么信号处理程序的执行就会被打断。如果进程上还有其它的待处理信号，那么当进程从核心态返回用户态时，就会执行新的信号处理程序。也就是说信号处理的过程可能是嵌套的。如果不希望发生这种嵌套现象，应在执行信号处理程序时阻塞其它的信号，如在sigaction结构的sa_mask位图中声明需阻塞的信号等。

值得注意的是Linux对信号SIGCHLD的处理。正常情况下，当线程组中最后一个进程终止时，它应该将自己的退出状态设为EXIT_ZOMBIE并向父进程发送SIGCHLD信号(见7.4.1节)。如果父进程为SIGCHLD自定义了处理程序，该信号会被父进程正常处理，如init进程。然而通常情况下，进程为SIGCHLD指定的处理程序都是忽略。按照POSIX约定，进程对SIGCHLD的忽略处理是反复执行函数wait4()，以回收所有处于僵死态的子进程。事实上，早期的Linux就是这样处理SIGCHLD信号的。这种约定虽然有效，但显得十分古怪(进程对信号SIGCHLD的缺省处理是忽略、忽略处理是回收子进程)。在新版本中，Linux修正了信号SIGCHLD的发送和处理方法，如下：

(1)如果父进程为SIGCHLD指定了自定义的处理程序，则正常发送，正常处理。

(2)如果父进程为SIGCHLD指定的处理程序是缺省，则直接将其丢弃。

(3)如果父进程为SIGCHLD指定的处理程序是忽略，则将子进程的退出状态改为EXIT_DEAD，并将它的task_struct结构的引用计数减1。如此以来，调度程序就会直接将子进程释放，不再需要麻烦父进程回收了。10.1.6信号接收

正常情况下，信号是异步的。进程不知道什么时候会收到信号，也不知道什么时候会处理信号。异步的信号虽然简单，但却让人觉得难以掌控。为此，新版本的Linux又提供了同步信号处理方式。

如果进程想用同步方式处理自己收到的信号，它可以采用如下方法：

(1)通过系统调用signalfd()或signalfd4()创建一个文件描述符，并在其中指定想要接收的信号种类(不包括SIGKILL和SIGSTOP)。

(2)通过系统调用sigprocmask()阻塞想要同步接收的信号。

(3)在需要时，直接通过系统调用read()读新建的文件描述符。如果进程已收到了指定的信号，read()会返回信号的描述信息，包括信号的编号和附加信息。如果进程还未收到指定的信号，进程将被挂在sighand_struct结构的signalfd_wgh队列中等待，直到指定的信号到来。

(4)当不再需要同步接收信号时，可通过系统调用close()关闭信号的描述符。

进程通过read()操作读出的信号会自动从进程的信号队列中删除。由signalfd()或signalfd4()创建的文件描述符也可用在通用的poll()或select()中，以查询或监视想要同步接收的信号。执行poll()或select()的进程会被阻塞，直到收到需要的信号或等待超时。

利用系统调用sigsuspend()或rt_sigsuspend()也可以实现信号的同步处理。想同步处理信号的进程可以定义一个阻塞位图，将希望接收信号的阻塞位清0，而后通过函数sigsuspend()或rt_sigsuspend()将进程的阻塞位图换成新定义的阻塞位图，并将自己挂起。如此以来，只有当期望的信号到来时，进程才会被唤醒。进程被唤醒后，其上的阻塞位图会被恢复，进程此前执行的函数sigsuspend()或rt_sigsuspend()会正常返回。

利用系统调用sigpending()或rt_sigpending()可以查询进程已收到、未被阻塞、未被处理的信号位图。

虽然可以带一个附加信息，但信号所传递的信息量毕竟十分有限，因而信号较适合于通知，却难以胜任大量信息的传递。要实现进程之间的大数据量通信，还必须提供其它的通信手段，如管道(Pipe)。管道机制最早由AT&T的M.D.Mcllroy提出，于1973年被引入Unix操作系统。管道是一项重要的发明，它使Unix具有了将小程序组合成大工具的能力，使Unix的优雅哲学(小的就是美的)得以充分体现。10.2管道10.2.1管道的意义

正常情况下，进程的虚拟地址空间是相互独立的，除内核之外，在不同进程的虚拟地址空间中没有重叠的部分，进程之间没有自然的通信渠道，无法进行直接通信。然而，若抽象掉程序、数据等的实际含义，可以将进程的虚拟地址空间看成一个字节的容器。只要在两个容器之间建立一条管道(Pipe)，一个进程中的字节(数据)就可以自然地流动到另一个进程中，如图10.3(a)所示。因而，管道是进程间一种最自然的通信方式。

图10.3基于管道的进程间通信在Linux的Shell命令中，管道由‘|’标识。由‘|’链接起来的多个命令会创建多个进程(每个命令对应一个进程)，进程间建立有自然的管道，前一个命令(或进程)的标准输出会被管道转化为后一个命令(或进程)的标准输入。如在命令“ls-l|wc-l”中，ls的输出(当前目录的内容)被管道直接递交给命令wc，用以统计其中的行数。

与现实世界中的管道不同，用于通信的管道具有如下特点：

(1)管道是单向的，数据只能从入口进程流向出口进程，不能逆向流动。

(2)管道中流动的数据是字节流，没有结构，通信的格式需要双方自己约定。

(3)管道是可靠的、有序的、先进先出的，流出的数据与流入的数据完全一致。

(4)管道有容量限制，当管道满时，发送端无法再发送字节；当管道空时，接收端无法再取出字节。10.2.2匿名管道

在多年的发展过程中，人们给出了多种管道实现方法。在两个进程之间建立Socket链接之后可以实现它们之间的通信。同一系统中的两个进程也可以利用普通文件实现通信(一个进程向文件尾部写数据，另一个进程从文件头部读数据)。然而，利用Socket实现的通信需要经过网络协议层的转换，其中有许多无谓的打包、拆包操作，开销较大。利用普通文件进行的通信不够灵活、速度较慢且浪费外存空间。因而，实用的管道应是对Socket或普通文件的简化。目前的Linux利用伪文件系统(称为pipefs)实现管道，该文件系统已在系统初始化时注册并安装。既然管道仅用作通信，那么管道文件就应该是一种临时文件，没有必要在外存设备上真正将其建立起来。如果用一块内存空间来模拟管道文件(如图10.3(b)所示)，那么对它的读写操作就可直接在内存中进行，从而可大大提升通信速度。基于上述考虑，Linux用内存中的临时文件实现其经典的管道。由于这种管道是动态建立和撤销的，在文件系统中没有体现，也没有名称，故被称为匿名管道。

匿名管道的建立由系统调用pipe()或pipe2()完成。两个系统调用的功能一样，只是后者比前者多一个标志，可用于设置管道文件的属性，如非阻塞读写等。函数pipe()或pipe2()会在pipefs的根目录中创建一个管道文件，并将其分别按只写和只读方式打开，而后返回两个文件描述符(两个整数，分别代表两个打开的文件)，其中的第0个描述符表示管道文件的读端口或出口，只能用于从中读数据，第1个描述符表示管道文件的写端口或入口，只能用于向其中写数据。也就是说，执行函数pipe()或pipe2()的进程会动态地创建一个管道文件，并得到它的两个端口的描述符，此后该进程可以用普通的write()操作向入口端写数据并用read()操作从出口端读数据，以实现基于管道的通信。当然，单个进程的自我通信是没有意义的。要想利用匿名管道实现双进程间的通信，就必须将管道的一端交给另一个进程。然而，文件描述符是进程私有的，在一个进程中使用另一个进程的文件描述符是非法的，因而不能直接将管道文件描述符交给另一个进程，除非这两个进程是父子关系。如果进程A在执行完pipe()或pipe2()之后创建进程B，那么A的整个文件描述符表都会被B继承，包括其中的两个管道文件描述符。此后，只要进程A关闭管道文件的一端，进程B关闭管道文件的另一端，即可在两进程之间建立起一个单向的管道，实现父子进程之间的通信。如果进程A在执行完pipe()或pipe2()之后创建两个进程B和C，那么B和C都会继承A的文件描述符表，包括其中的两个管道文件描述符。此后，只要进程B关闭管道文件的一端，进程C关闭管道文件的另一端，即可在两进程之间建立起一个单向的管道，实现兄弟进程之间的通信。事实上，利用匿名管道只能实现父子进程或兄弟进程之间的通信，如图10.4所示。

图10.4父子进程之间的通信管道为了提高内存的利用率，管道所用的内存空间也是动态分配的，每次至少1页，缺省情况下管道的大小可达16页，如图10.5所示。

在图10.5中，buffers是管道缓冲区的最大允许页数，nrbufs是管道中的当前页数，curbuf是位于管道首部的物理页。物理页的分配由写操作负责。当写操作发现管道尾部的剩余空间不够用时，它向物理内存管理器申请1个高端页，并将其链接在管道的尾部。当读操作将管道头部的物理页读空后，它直接将其释放。管道是典型的生产者/消费者问题，其操作具有自然的同步能力。当写操作发现管道满时，写进程被挂在wait队列上等待，直到被读进程唤醒。当读操作发现管道中的内容不够读时，读进程被挂在wait队列上等待，直到被写进程唤醒。

图10.5匿名管道的管理结构生产者在发送完毕之后可以直接通过close()操作关闭自己一方的管道。当读完管道中的数据后，消费者会得到一个EOF(EndofFile)标志，此时，它可以关闭自己一方的管道。当两方都关闭以后，管道才会被释放。如果消费者因为某种原因而提前关闭管道，那么生产者会在写操作中发现管道已经断裂(读方已不存在)，会收到一个SIGPIPE信号。生产者可以在SIGPIPE信号的处理程序中关闭管道。10.2.3命名管道

匿名管道简单但能力有限，只能用于父子、兄弟进程之间的通信，不能成为一种通用的进程间通信机制，原因是匿名管道“无名”、“无形”，只能被隐式地继承而不能被显式地声明。只有当管道“有名”、“有形”时，它才可能被任意两个进程打开，从而实现任意两个进程之间的通信。称这种“有名”、“有形”的管道为命名管道(FIFO)。

命名管道是外存设备上的一种特殊类型的文件，类型为FIFO，且有一个永久性的名字。与普通文件不同，由于不需要在其中真正保存数据，因而命名管道仅需要一个管理结构(文件控制块inode)，不需要占用外存设备的其它存储空间。只要知道命名管道的名称，所有进程都可按需要的方式打开命名管道，并通过它实现进程间的通信。

使用命名管道的方法如下：

(1)读进程按只读方式打开命名管道文件，获得命名管道的文件描述符。

(2)写进程按只写方式打开命名管道文件，获得命名管道的文件描述符。

(3)写进程向管道中写数据，读进程从管道中读数据，实现相互通信。

(4)通信完成之后，各自关闭命名管道文件。

命名管道的管理结构与匿名管道的相同。第一个打开命名管道的进程创建管理结构。通常情况下，执行打开操作的进程会被阻塞直到命名管道的另一端也被打开。按读方式打开的命名管道不能写，按写方式打开的命名管道不能读，但命名管道允许按读写方式打开。按读写方式打开的命名管道既允许读又允许写，是一种双向的管道。与匿名管道不同，一个命名管道可以被多个进程打开。也就是说，一个命名管道可以同时有多个写者和多个读者。写入命名管道的数据被按序保存在缓冲区中，不区分写者；读者从缓冲区的头部按序读出数据，也不区分读者。数据被读出后即从命名管道中消失。显然，命名管道比匿名管道功能更强，也更加灵活。

不管是命名管道还是匿名管道，在其中传递的都是没有经过任何包装的裸数据。这种通信方式的效率虽然很高，但却丢失了通信所需要的许多信息，如发送者、接收者、时间、类型、长度、边界等。因而管道通信的适用范围十分有限，有必要提供更符合人类习惯的进程间通信机制，如消息队列(MessageQueue)。10.3消息队列与面向连接的管道通信不同，消息队列是一种面向消息的、无连接的异步通信机制，更像是基于邮箱(Mailbox)的通信。发送者将包装后的消息放到邮箱中，接收者在方便的时候从邮箱中取走自己需要的整条消息。消息的发送者和接收者不需要同时存在。通过消息队列，发送者和接收者之间可以建立起多种形式的通信关系，如一对一、一对多、多对一、多对多等。

早期的Linux仅实现了符合UnixSystemV规范的消息队列，所采用的管理机制与信号量集合相似(见9.6)。新版本的Linux增加了符合POSIX标准的消息队列，所采用的管理机制与文件系统相同。10.3.1SystemV消息队列

1970年，为了支持数据库和事务处理，Bell实验室在自己内部的Unix版本中首次引入了三种进程间通信(InterprocessCommunication，IPC)机制，包括消息队列、信号量集合和共享内存。1983年，在SystemV发布之时，这三种IPC机制被正式集成到了Unix操作系统中，遂被统称为UnixSystemV的IPC机制。

SystemV的三种IPC机制具有相似的编程接口和使用方法。与信号量集合相似，Linux为它的每个消息队列都定义了一个证书(结构kern_ipc_perm)，用于描述消息队列的基本属性，如键值(外部名称)key、内部标识id、创建者的uid和gid、拥有者的uid和gid、访问权限mode、序列号seq、安全证书security等。其中键值key是一个整数或者魔数，是用户为消息队列起的名称。消息队列由键值命名，由id号标识。进程使用消息队列的过程如下：

(1)通过其它途径(如预先约定等)获得消息队列的键值。

(2)打开消息队列，核对访问权限，获得id号。第一个打开者创建消息队列。

(3)通过id号对消息队列进行初始化，而后在其上执行发送、接收操作。

(4)由最后一个使用者释放并销毁消息队列。

消息队列是动态创建的。Linux用结构msg_queue描述消息队列，主要内容如下：

(1)证书q_perm是一个kern_ipc_perm结构，描述消息队列的基本属性。

(2)字节数q_cbytes是一个无符号长整数，表示队列中当前的消息总长度。

(3)消息数q_qnum是一个无符号长整数，表示队列中当前的消息条数。

(4)容量q_qbytes是一个无符号长整数，表示队列的最大容量(字节数)。

(5)队列q_messages是通用链表的表头，用于组织队列中的所有消息。

(6)队列q_receivers是通用链表的表头，用于组织等待从队列中接收消息的进程。

(7)队列q_senders是通用链表的表头，用于组织等待向队列中发送消息的进程。图10.6SystemV的消息队列管理结构发送到队列中的消息由正文和消息头构成，消息头由结构msg_msg描述，如下：

structmsg_msg{

structlist_head m_list; //队列节点

long m_type; //消息类型

int m_ts; //消息正文的长度

structmsg_msgseg *next; //消息正文的附加段

void *security; //消息的安全标识

};正常情况下，消息正文紧跟着消息头。如果消息较短(包装后的长度不超过一页)，整条消息会被集中存放在一块连续的内存空间中。如果消息较长(包装后的长度超过一页)，消息正文会被分成几部分，每一部分的长度都不超过一页。长消息的第一部分带着消息头，其余部分(称为附加段)的前面带一个指针，用于将长消息的所有附加段串成一个单向队列。消息头中的next是附加段队列的队头。

消息队列具有同步能力。当消息队列达到或接近容量极限，无法再容纳新的消息时，发送进程被挂在q_senders中等待；当消息队列中没有需要类型的消息时，接收进程被挂在q_receivers中等待。早期的Linux用一个静态的全局指针数组(长度为128)组织系统中的消息队列，虽然简单但不够灵活。新版本的Linux改用IDR(IDRadix)树来组织消息队列，每个IPC名字空间一棵，IDR树的树根记录在IPC名字空间中，如图10.7所示。消息队列的ID号id、在IDR树中的索引号idx与序列号seq(记录在证书结构kern_ipc_perm中)之间的关系为id=idx+32768

×

seq，idx=id%32768。

打开消息队列的操作是msgget()，需要的参数有两个，一是消息队列的键值key，二是消息队列的访问权限。打开操作搜索申请者进程的名字空间(实际是它的IDR树)，以确定键值为key的消息队列是否已在其中。如果在，说明该消息队列已被其它进程创建，只要申请者能通过它的权限检查，即可返回它的id号。如果不在，说明该消息队列还未被建立，需要创建一个新的消息队列，并返回它的id号。

图10.7基于IDR树的消息队列管理结构创建新消息队列的工作如下：

(1)在当前IDR树中为新消息队列找一个空槽位，确定其索引号和id号。

(2)创建一个msg_queue结构，设置其中的key、id、seq、uid、gid等域，并将其插入到IDR树中。

在获得消息队列的id号之后，通过函数msgctl()可对其进行管理操作，如：

(1)通过操作MSG_INFO获取当前名字空间中消息队列的状态信息，包括允许创建的最大消息队列数、单个消息的最大长度(字节)、单个消息队列的最大容量(字节)、单个消息中的最大附加段数、当前已创建的消息队列数等。

(2)通过操作MSG_STAT获取特定消息队列的状态信息，包括队列的证书、队列中的消息数、队列中的字节数、最近一次发送时间、最近一次接收时间等。

(3)通过操作IPC_SET设置特定消息队列的属性，包括uid、gid、访问权限、队列的最大容量等。消息队列有容量限制，虽然容量是可调的。

(4)通过操作IPC_RMID销毁特定的消息队列，包括其中的所有消息，同时唤醒在该消息队列上等待的所有进程。

向消息队列发送消息的操作是msgsnd()，需要的参数有消息队列的id号、用户空间中的消息缓冲区、消息正文的长度和特殊的发送要求(如非阻塞发送)等。每个消息都有一个类型，其含义由发送者和接收者自己约定(见表10.2)。消息类型与消息正文一起记录在消息缓冲区中，类型在前(占四个字节)正文在后。消息发送的过程如下：

(1)根据id号找到消息队列(msg_queue结构)，进行必要的权限检查。

(2)如果消息队列已没有足够的空间来接纳新的消息，且发送者未声明非阻塞发送，则将发送者进程挂在队列q_senders中等待，直到接收者为其腾出足够的空间。

(3)如果可以接收新消息，则将用户缓冲区中的消息正文读入内核，将其加上消息头(msg_msg结构)后挂在队列q_messages中。如果消息正文较长，要将其拆分成附加段。

(4)如果队列q_receivers中有等待接收消息的进程，且新到来的消息能满足其中某个等待者的需求，则将该等待进程唤醒。

从消息队列中接收消息的操作是msgrcv()，需要的参数有消息队列的id号、用户空间中的消息缓冲区、消息正文的长度、期望接收的消息类型和特殊的接收要求(如非阻塞接收)等。与管道不同，接收者可以通过消息类型指定自己期望接收的消息(不一定是队列中的第一个消息)。消息类型的含义如表10.2所示。

表10.2消息类型的含义消息接收的过程如下：

(1)根据id号找到消息队列(msg_queue结构)，进行必要的权限检查。

(2)如果消息队列中没有满足要求的消息，且接收者未明确声明非阻塞接收，则将接收者进程挂在队列q_receivers中等待，直到被发送者唤醒。

(3)如果消息队列中有满足要求的消息，则将其从队列中摘下，将其内容拷贝到用户空间的缓冲区中，并释放消息所占用的内存空间。

(4)如果队列q_senders中有等待发送消息的进程，则唤醒其中的第一个等待者。

值得注意的是，队列中的每条消息都是完整的实体，消息与消息之间有严格的边界，消息只能被整条发送和接收，不能仅发送或接收部分消息。另外，等待发送或接收消息的进程处于可中断等待状态，可被信号唤醒。被信号唤醒的发送或接收者进程将错误返回，表示发送或接收失败。

SystemV的消息队列虽然灵活，但存在着一些问题，如：

(1)与Linux的其它I/O机制不兼容。在Linux中，所有的输入/输出都已被统一在虚拟文件系统的框架之内，但消息队列是一个例外。虽然消息队列借用了文件系统的实现思想，但其标识方法(键值而不是文件名)、使用方法(不是打开、读写、关闭)等都与标准的文件操作不同，需要为其提供专门的管理工具。

(2)难以确定销毁时机。消息队列是一种无链接的通信机制，不需要通信各方同时存在。也就是说消息队列可以离开发送者和接收者进程独立存在，通过消息队列可以向未来某个时刻启动的进程传递信息。消息队列的这一特性使内核无法确定其销毁时机，过早销毁会丢失队列中的消息，忘记销毁则会使队列及其中的消息成为内存垃圾。

事实上，SystemV的三种IPC机制中都存在上述问题。所以有人建议应尽量避免使用SystemV的消息队列，而代之以命名管道或POSIX消息队列。10.3.2POSIX消息队列

POSIX的IPC是模仿SystemV的IPC制定的，目的是为了解决SystemV的上述问题。POSIX的IPC也包含三种机制，分别是消息队列、信号量集合和共享内存。POSIX称IPC机制中的单个个体为对象，如一个POSIX消息队列被称为一个消息队列对象。

与SystemV的IPC不同，POSIX将自己的三种IPC机制全都集成在了虚拟文件系统框架之内，或者说POSIX将它的IPC对象也都看成是文件，采用与普通文件相同或相似的方式来操作和使用它们。在POSIX中，IPC对象的标识方式不再是键值而是文件名，如“/myqueue”。在使用IPC对象之前需要用open()操作将其打开并获得描述符。如果指定名称的IPC对象不存在，open()操作会为其创建一个新的对象。在获得IPC对象的描述符后，可以对其进行需要的操作，如在消息队列对象上进行发送、接收操作，在信号量对象上进行P、V操作等。用完后的IPC对象需要用close()操作关闭。

POSIX在每个IPC对象上都关联了一个引用计数，用于记录该对象被打开的次数。对象每被打开一次，它的引用计数就被加1，每被关闭一次，它的引用计数就被减1。引用计数为0的对象可被销毁。在对象被销毁之后，新的open()操作会再次创建指定名称的IPC对象。

为了管理POSIX的消息队列，Linux为它的每个IPC名字空间都专门建立了一个名为mqueue的伪文件系统(用户不可见)。与常见的文件系统不同，mqueue中仅有一个根目录，每个动态创建的消息队列对象都是根目录中的普通文件。在系统初始化时，mqueue已被注册并安装，它的安装结构已被记录在IPC名字空间中。与SystemV的消息队列不同，POSIX的消息队列具有双重身份。在mqueue文件系统中，消息队列是普通文件，其描述结构是inode和目录项(dentry结构)；在IPC中，消息队列就是消息队列，其描述结构中定义有消息的等待队列和进程的等待队列。因而POSIX的消息队列描述结构是两种身份的组合。Linux为POSIX消息队列所定义的管理结构是mqueue_inode_info，如图10.8所示。

图10.8POSIX单个消息队列的管理结构

POSIX消息队列的队列属性由域attr描述，其中的主要内容包括mq_maxmsg(消息队列容量，即最多可容纳的消息数)、mq_msgsize(单个消息的最大长度，单位为字节)、mq_

curmsgs(队列中当前的消息数)和mq_flags(队列的操作标志，如是否允许非阻塞发送和接收等)。消息队列的容量是在创建时指定的，在使用过程中不可再改变。

在POSIX消息队列中，用于暂存消息的不是一个链表而是一个指针数组messages，其大小与队列属性中的最大消息数mq_maxmsg相等。与SystemV的消息队列相同，POSIX的消息也被包装在结构msg_msg中，但消息类型m_type被重新解释成了优先级。在数组messages中的消息按优先级排序，优先级低的在前，优先级高的在后。messages[0]所指消息的优先级最低，messages[mq_curmsgs-1]所指消息的优先级最高。进程接收的总是优先级最高的消息。

如果消息队列已满，发送者应该等待，e_wait_q[0]是发送者进程等待队列；如果消息队列已空，接收者应该等待，e_wait_q[1]是接收者进程等待队列。与SystemV的等待队列不同，POSIX的等待队列是有序的，高优先级的进程在前，低优先级的进程在后。与SystemV的消息队列不同，POSIX允许为消息队列选择一种通知方式，如信号，以支持异步接收。当空消息队列首次收到新消息时，如果e_wait_q[1]中没有等待的接收者，系统将向预定消息的接收者发送一个信号。信号的编号记录在mqueue_inode_info结构的notify域中，信号的接收者记录在notify_owner域中。进程可以通过系统调用mq_notify()预定消息。

POSIX消息队列的文件属性由域vfs_inode描述，其主要内容包括访问权限i_mode、inode_operations操作集、file_operations操作集等。每个inode结构都关联着一个目录项结构dentry，其中记录着消息队列的名称和组织关系，如父、子关系等。系统中所有的目录项，包括消息队列目录项，都被组织在一个名为dentry_hashtable的全局Hash表中。消息队列目录项的Hash值是根据队列的名称和根目录的地址算出的。给出一个消息队列名，查IPC名字空间可获得mqueue文件系统的根目录，查表dentry_hashtable可找到消息队列的dentry结构和与之关联的inode结构，进而可获得该消息队列的管理结构mqueue_inode_info。图10.9是IPC名字空间中消息队列的组织结构。

图10.9IPC名字空间中消息队列的组织结构当进程打开消息队列时，Linux会根据名称查Hash表dentry_hashtable。如果指定名称的消息队列不在该Hash表中，则要为其创建一个新对象。进程在创建新消息队列时需要指定访问权限和属性。新消息队列的创建过程如下：

(1)创建一个dentry结构，将其d_name设为新消息队列的名称。

(2)将新建的dentry插入到mqueue文件系统的根目录(作为根目录中的普通文件)和Hash表dentry_hashtable中。

(3)创建一个mqueue_inode_info结构(包括messages数组)并对其进行初始化，包括设置其中的vfs_inode部分(i_mode、i_uid、i_fop等)和属性部分attr，而后将新建的dentry与vfs_inode关联起来。

(4)创建一个file结构，设置它的f_mode、f_path、f_pos、f_op等，并将其插入到进程的文件描述符表中。结构file在文件描述符表中的索引就是新消息队列的描述符。如果进程要打开的消息队列在表dentry_hashtable中，说明它已被其它进程创建，其dentry和mqueue_inode_info结构已经存在。此时的打开操作仅需完成两件事，一是核对进程的访问权限，二是创建一个新的file结构并将其插入到进程的文件描述符表中。

在获得消息队列的描述符之后，可以向其发送消息。向消息队列发送消息的操作是mq_timedsend()，需要的参数有消息队列的描述符、用户空间的消息缓冲区、消息正文的长度、消息的优先级、最长等待时间等。消息的发送过程如下：

(1)用消息队列的描述符查进程的描述符表，找到与之对应的file结构，进而得到它的dentry结构、inode结构和mqueue_inode_info结构，进行必要的权限检查。

(2)将用户空间的消息拷贝到内核，将其包装在msg_msg结构中，将其类型m_type设为消息的优先级。

(3)如果队列已满且不允许非阻塞发送，则启动一个高精度定时器，而后按优先级从大到小的顺序将发送者进程挂在e_wait_q[0]中等待。进程醒来的原因有三：

①定时器到期，说明一直没有接收者读取消息，发送失败。②收到信号，说明进程遇到了需要紧急处理的事件，发送失败。

③队列中出现空缺，说明已有消息被用户取走，可以再次尝试发送。

(4)如果队列未满或已出现空缺，则将消息按优先级从小到大的顺序插入到数组messages中。

(5)如果队列上有等待的接收者，则唤醒e_wait_q[1]中的第一个进程(优先级最高)。如果没有等待的接收者，且队列中没有其它的消息，则通知预定的接收者。从消息队列中接收消息的操作是mq_timedreceive()，需要的参数有消息队列的描述符、用户空间的消息缓冲区、缓冲区的长度、消息的优先级、最长等待时间等。消息的接收过程如下：

(1)用消息队列的描述符查进程的描述符表，找到与之对应的file结构，进而得到它的dentry结构、inode结构和mqueue_inode_info结构，进行必要的权限检查。

(2)如果队列已空且不允许非阻塞接收，则启动一个高精度定时器，而后按优先级从大到小的顺序将接收者进程挂在e_wait_q[1]中等待。进程醒来的原因有三：①定时器到期，说明一直没有消息到来，接收失败。

②收到信号，说明进程遇到了需要紧急处理的事件，接收失败。

③队列中出现新消息，可以再次尝试接收。

(3)如果队列非空，则将优先级最高的消息从messages数组中摘下，将其内容和优先级拷贝到用户空间的消息缓冲区中，而后释放消息所占用的内核内存空间。

(4)如果有等待发送的进程，则唤醒e_wait_q[0]中的第一个等待者。当不再需要向消息队列发送消息或从消息队列接收消息时，进程可以将打开的消息队列关闭。关闭操作是close()，所需的参数是消息队列的描述符，所完成的工作是释放描述符所对应的file结构。与普通文件的关闭操作一样，消息队列的关闭操作也不会将队列对象销毁。

彻底销毁消息队列的操作是mq_unlink()，需要提供的参数是消息队列的名称。操作mq_unlink()所完成的工作与创建相反，包括：

(1)根据名称查Hash表dentry_hashtable找到与之对应的dentry并进行权限检查。

(2)递减dentry中的引用计数。如果引用计数大于0，说明该消息队列还有用户，不能将其销毁。如果引用计数为0，则销毁消息队列：

①释放队列中的所有消息。

②释放队列的mqueue_inode_info结构，包括其中的massages数组。

③将dentry结构从dentry_hashtable表和目录树中删除并释放。

由此可见，POSIX消息队列本身并未定义引用计数，它使用的引用计数实际是从目录项结构dentry中借用的。

虽然用管道和消息队列可以实现进程之间的通信，但它们的通信代价都比较高。在通信时，发送方需要将数据从用户空间拷贝到内核空间，接收方需要将数据从内核空间再拷贝回用户空间。数据的来回拷贝既浪费了内存又浪费了时间，应该尽量避免。10.4共享内存事实上，如果能在两个进程之间建立一块共用的物理内存空间，那么它们之间就可以直接交换信息。一个进程对共用内存空间的修改可以立刻被另一个进程看到，数据不需要在进程之间来回拷贝，参与通信的进程不需要执行专门的发送和接收操作，通信过程也不需要内核介入，因而可极大地提升通信的速度。这种利用共用物理内存空间实现的进程间通信称为共享内存(sharedmemory)，是一种最快速的通信方式。共享内存的问题是它可能被多个进程同时访问。为了保证通信的可靠性，需要其它手段来实现进程间的互斥与同步。当然，互斥与同步操作会降低通信的速度。由于正常情况下的进程之间没有共享的虚拟内存，因而共享内存的建立需要操作系统内核的支持。Linux提供了多种建立共享内存的系统调用，如共享文件映射、SystemV方式的共享内存、POSIX方式的共享内存等。10.4.1共享文件映射

文件映射的作用是建立虚拟内存区域，即在文件区间与进程虚拟地址空间之间建立映射关系。映射之后的文件可以直接访问，就像它们已被读入内存一样，不需要再执行专门的read()、write()操作。若进程访问的内容未被读入内存，处理器会产生页故障异常，虚拟内存管理器会找到与之对应的文件页并将其读入。因此，文件映射是进程使用文件的一种极为简洁的方法。如果将一个文件区间同时映射到多个进程的虚拟地址空间中(在每个进程中建立一个虚拟内存区域)，那么该文件区间就会变成进程之间的公共内存区间。也就是说，可以利用文件映射在进程之间建立共享内存。可执行文件的加载操作(exec类操作)是一种隐式的文件映射操作，mmap()是一种显式的文件映射操作。加载操作建立的是私有映射(对应的虚拟内存区域称为私有区域)，且一次会建立多个虚拟内存区域。mmap()操作既可建立私有映射也可建立共享映射(对应的虚拟内存区域称为共享区域)，且一次仅会建立一个虚拟内存区域。

如果进程仅在私有区域上执行读操作，那么系统仅会在物理内存中保留一份文件内容。用于保存文件内容的物理页出现在多个进程的页表中，是它们的共享内存区间。如果进程在私有区域上执行了写操作，虚拟内存管理器会立刻为其建立一个私有的拷贝。私有拷贝不再是进程之间的共享区间，一个进程写入其中的内容无法被其它进程看到，也不会被写入映射文件，因而利用私有映射无法实现进程之间的通信。与私有区域不同，不管进程在共享区域上执行读操作还是写操作，虚拟内存管理器仅会在物理内存中保留一份文件内容，用于保存文件内容的物理页可能被共享它的所有进程访问。按共享方式映射同一文件区间的所有进程都可对其进行读写操作，一个进程写入的内容可以立刻被其它进程看到，进程对共享区间的修改结果也会被写回映射文件。因而，利用共享文件映射可以实现进程之间的通信，如图10.10所示。

图10.10通过共享文件映射实现的共享内存在图10.10中，文件中的两页按共享方式被同时映射到进程1和进程2的虚拟地址空间中，这两页的内容在物理内存中仅有一个拷贝，进程1和进程2都可对这两个物理页进行读写操作，一个进程对它的修改可以立刻被另一个进程看到，修改结果也会被写回映射文件。进程1和进程2通过共享文件映射建立起了共享内存。

用于建立文件映射的操作是mmap()，该函数需要6个参数，分别是文件描述符fd、区间在文件中的开始位置offset、区间的长度length、虚拟内存区域的开始位置addr、映射方式flags(私有、共享等)和虚拟内存区域的访问权限prot(读、

写)。

如果申请者未指定参数addr，虚拟内存管理器将为其选择一个适当的映射位置。即使申请者