**
前言
**
大多数重要的程序都涉及进程间通信（Interprocess Communication, IPC）。这是受下述设计原则影响的自然结果：把应用程序设计为一组相互通信的小片断比将其设计为单个庞大的程序更好。从历史角度看，应用程序有如下几种构建方法。
（1）用一个庞大的程序完成全部工作。程序的各部分可以实现为函数，函数之间通过参数、返回值和全局变量来交换信息。
（2）使用多个程序，程序之间用某种形式的IPC进行通信。许多标准的Unix工具都是按这种风格设计的，它们使用shell管道（IPC的一种形式）在程序之间传递信息。
（3）使用一个包含多个线程的程序，线程之间使用某种IPC。这里仍然使用术语IPC，尽管通信是在线程之间而不是在进程之间进行的。
还可以把后两种设计形式结合起来：用多个进程来实现，其中每个进程包含几个线程。在这种情况下，进程内部的线程之间可以通信，不同的进程之间也可以通信。
上面讲述了可以把完成给定任务所需的工作分到多个进程中，或许还可以进一步分到进程内的多个线程中。在包含多个处理器（CPU）的系统中，多个进程也许可以（在不同的CPU上）同时运行，或许给定进程内的多个线程也能同时运行。因此，把任务分到多个进程或线程中有望减少完成指定任务的时间。
本书详细描述了以下4种不同的IPC形式：
（1）消息传递（管道、FIFO和消息队列）；
（2）同步（互斥量、条件变量、读写锁、文件和记录锁、信号量）；
（3）共享内存（匿名的和具名的）；
（4）远程过程调用（Solaris门和Sun RPC）。
本书不讨论如何编写通过计算机网络通信的程序。这种通信通常涉及使用TCP/IP协议族的套接字API，相关主题在第1卷[Stevens 1998]中有详细讨论。
有人可能会提出质疑：不应该使用单主机或非网络IPC（本卷的主题），所有程序都应该在网络上的多台主机上同时运行。但在日常实践中，单主机IPC往往比网络通信快得多，而且有时还简单些。共享内存、同步等方法通常也只能用于单主机，跨网络时可能无法使用。经验和历史表明，非网络IPC（本卷）与跨网络IPC（第1卷）都是需要的。
目录
**[第1章 简介
1.1 概述]()**
1.2 进程、线程与信息共享
1.3 IPC对象的持续性
1.4 名字空间
1.5 fork、exec和exit对IPC对象的影响
1.6 出错处理：包裹函数
1.7 Unix标准
1.7.1 osix
1.7.2 Open Group
1.7.3 Unix版本和移植性
1.8 书中IPC例子索引表
1.9 小结
**[第2章 Posix IPC
2.1 概述]()**
2.2 IPC名字
2.3 创建与打开IPC通道
2.4 IPC权限
2.5 小结