Linux 进程间通信

最新推荐文章于 2024-03-07 10:06:04 发布

itakyubi

最新推荐文章于 2024-03-07 10:06:04 发布

阅读量249

点赞数

分类专栏： linux 文章标签： linux

本文链接：https://blog.csdn.net/itakyubi/article/details/100045808

版权

linux 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

3、报文(Message)队列（消息队列）

(3) Socket一般应用模式（服务端和客户端）

(4) Socket通信基本流程图

(5) 使用unix域协议的例子

7、消息队列、信号量以及共享内存的相似之处

8、XSI IPC和PIPE、FIFO的区别

1、管道

管道包括三种：

普通管道(pipe)：通常有两种限制，一是单工，只能单向传输；二是只能在父子或者兄弟进程间使用。
流管道(s_pipe)：去除了第一种限制，为半双工，只能在父子或兄弟进程间使用，可以双向传输。
命名管道(name_pipe)：去除了第二种限制，可以在许多并不相关的进程之间进行通讯。

(1) 管道的通信

管道是由内核管理的一个缓冲区，相当于我们放入内存中的一个纸条。管道的一端连接一个进程的输出。这个进程会向管道中放入信息。管道的另一端连接一个进程的输入，这个进程取出被放入管道的信息。一个缓冲区不需要很大，它被设计成为环形的数据结构，以便管道可以被循环利用。当管道中没有信息的话，从管道中读取的进程会等待，直到另一端的进程放入信息。当管道被放满信息的时候，尝试放入信息的进程会等待，直到另一端的进程取出信息。当两个进程都终结的时候，管道也自动消失。

(2) 管道的创建

从原理上，管道利用fork机制建立，从而让两个进程可以连接到同一个PIPE上。最开始的时候，上面的两个箭头都连接在同一个进程Process 1上(连接在Process 1上的两个箭头)。当fork复制进程的时候，会将这两个连接也复制到新的进程(Process 2)。随后，每个进程关闭自己不需要的一个连接 (两个黑色的箭头被关闭; Process 1关闭从PIPE来的输入连接，Process 2关闭输出到PIPE的连接)，这样，剩下的红色连接就构成了如上图的PIPE。

(3) 管道的内核实现

在 Linux 中，管道的实现并没有使用专门的数据结构，而是借助了文件系统的file结构和VFS的索引节点inode。通过将两个 file 结构指向同一个临时的 VFS 索引节点，而这个 VFS 索引节点又指向一个物理页面而实现的。如下图

有两个 file 数据结构，但它们定义文件操作进程地址是不同的，其中一个是向管道中写入数据的进程地址，而另一个是从管道中读出数据的进程地址。这样，用户程序的系统调用仍然是通常的文件操作，而内核却利用这种抽象机制实现了管道这一特殊操作。

(4) 管道的读写

管道实现的源代码在fs/pipe.c中，在pipe.c中有很多函数，其中有两个函数比较重要，即管道读函数pipe_read()和管道写函数pipe_wrtie()。管道写函数通过将字节复制到 VFS 索引节点指向的物理内存而写入数据，而管道读函数则通过复制物理内存中的字节而读出数据。当然，内核必须利用一定的机制同步对管道的访问，为此，内核使用了锁、等待队列和信号。

当写进程向管道中写入时，它利用标准的库函数write()，系统根据库函数传递的文件描述符，可找到该文件的 file 结构。file 结构中指定了用来进行写操作的函数（即写入函数）地址，于是，内核调用该函数完成写操作。写入函数在向内存中写入数据之前，必须首先检查 VFS 索引节点中的信息，同时满足如下条件时，才能进行实际的内存复制工作：

内存中有足够的空间可容纳所有要写入的数据；
内存没有被读程序锁定。

如果同时满足上述条件，写入函数首先锁定内存，然后从写进程的地址空间中复制数据到内存。否则，写入进程就休眠在 VFS 索引节点的等待队列中，接下来，内核将调用调度程序，而调度程序会选择其他进程运行。写入进程实际处于可中断的等待状态，当内存中有足够的空间可以容纳写入数据，或内存被解锁时，读取进程会唤醒写入进程，这时，写入进程将接收到信号。当数据写入内存之后，内存被解锁，而所有休眠在索引节点的读取进程会被唤醒。

管道的读取过程和写入过程类似。但是，进程可以在没有数据或内存被锁定时立即返回错误信息，而不是阻塞该进程，这依赖于文件或管道的打开模式。反之，进程可以休眠在索引节点的等待队列中等待写入进程写入数据。当所有的进程完成了管道操作之后，管道的索引节点被丢弃，而共享数据页也被释放。

(5) 管道的函数实现

a、Linux函数原型：

#include <unistd.h>

int pipe(int filedes[2]);

filedes[0]用于读出数据，读取时必须关闭写入端，即close(filedes[1]);

filedes[1]用于写入数据，写入时必须关闭读取端，即close(filedes[0])。

b、程序实例：

int main(void)
{
    int n;
    int fd[2];
    pid_t pid;
    char line[MAXLINE];

    // 先建立管道得到一对文件描述符
    if (pipe(fd) 0){
        exit(0);
    }
    
    // 父进程把文件描述符复制给子进程
    if ((pid = fork()) 0){
        exit(1);
    }else if (pid > 0){ // 父进程写
        close(fd[0]); // 关闭读描述符
        write(fd[1], "\nhello world\n", 14);
    }else{ // 子进程读
        close(fd[1]); // 关闭写端
        n = read(fd[0], line, MAXLINE);
        write(STDOUT_FILENO, line, n);
    }

    exit(0);
}

(6) 命名管道

由于基于fork机制，所以管道只能用于父进程和子进程之间，或者拥有相同祖先的两个子进程之间 (有亲缘关系的进程之间)。为了解决这一问题，Linux提供了FIFO方式连接进程。FIFO又叫做命名管道(named PIPE)。

a、实现原理

FIFO (First in, First out)为一种特殊的文件类型，它在文件系统中有对应的路径。当一个进程以读(r)的方式打开该文件，而另一个进程以写(w)的方式打开该文件，那么内核就会在这两个进程之间建立管道，所以FIFO实际上也由内核管理，不与硬盘打交道。之所以叫FIFO，是因为管道本质上是一个先进先出的队列数据结构，最早放入的数据被最先读出来，从而保证信息交流的顺序。FIFO只是借用了文件系统(file system,命名管道是一种特殊类型的文件，因为Linux中所有事物都是文件，它在文件系统中以文件名的形式存在。)来为管道命名。写模式的进程向FIFO文件中写入，而读模式的进程从FIFO文件中读出。当删除FIFO文件时，管道连接也随之消失。FIFO的好处在于我们可以通过文件的路径来识别管道，从而让没有亲缘关系的进程之间建立连接。

b、函数原型

#include <sys/types.h>
#include <sys/stat.h>

int mkfifo(const char *filename, mode_t mode);
int mknode(const char *filename, mode_t mode | S_IFIFO, (dev_t) 0);

其中filename是被创建的文件名称，mode表示将在该文件上设置的权限位和将被创建的文件类型(在此情况下为S_IFIFO)，dev是当创建设备特殊文件时使用的一个值。因此，对于先进先出文件它的值为0。

c、程序实例

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>

int main()
{
    int res = mkfifo("/tmp/my_fifo", 0777);
    if (res == 0){
        printf("FIFO created/n");
    }
    exit(EXIT_SUCCESS);
}

2、信号

(1) 信号的本质

信号是在软件层次上对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。
信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。

(2) 信号的来源

信号事件的发生有两个来源：

硬件来源(比如我们按下了键盘或者其它硬件故障)；
软件来源，最常用发送信号的系统函数是kill, raise, alarm和setitimer以及sigqueue函数，软件来源还包括一些非法运算等操作。

(3) 信号的种类

可靠性方面：可靠信号与不可靠信号；
与时间的关系上：实时信号与非实时信号。

可靠信号就是实时信号，那些从UNIX系统继承过来的信号都是非可靠信号，表现在信号不支持排队，信号可能会丢失，比如发送多次相同的信号，进程只能收到一次。信号值小于SIGRTMIN的都是非可靠信号。

非可靠信号就是非实时信号，后来，Linux改进了信号机制，增加了32种新的信号，这些信号都是可靠信号，表现在信号支持排队，不会丢失，发多少次，就可以收到多少次。信号值位于 [SIGRTMIN, SIGRTMAX] 区间的都是可靠信号。

a、不可靠信号

Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做”不可靠信号”，信号值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信号都是不可靠信号。这就是”不可靠信号”的来源。它的主要问题是：

进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。
信号可能丢失，因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。
Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。因此，Linux下的不可靠信号问题主要指的是信号可能丢失。

b、可靠信号

随着时间的发展，实践证明了有必要对信号的原始机制加以改进和扩充,力图实现”可靠信号”。由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。
信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()

注意：可靠信号是指后来添加的新信号（信号值位于SIGRTMIN及SIGRTMAX之间）；不可靠信号是信号值小于SIGRTMIN的信号。信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。

c、实时信号与非实时信号

非实时信号都不支持排队，都是不可靠信号，编号是1-31,0是空信号；实时信号都支持排队，都是可靠信号。

d、进程对信号的响应

忽略信号，即对信号不做任何处理，其中，有两个信号不能忽略：SIGKILL及SIGSTOP；
执行缺省操作，Linux对每种信号都规定了默认操作
捕捉信号。定义信号处理函数，当信号发生时，执行相应的处理函数；

注意：进程对实时信号的缺省反应是进程终止。

(4) 信号的发送和安装

发送信号的主要函数有：kill()、raise()、 sigqueue()、alarm()、setitimer()以及abort()。
如果进程要处理某一信号，那么就要在进程中安装该信号。安装信号主要用来确定信号值及进程针对该信号值的动作之间的映射关系，即进程将要处理哪个信号；该信号被传递给进程时，将执行何种操作。

注意： Linux主要有两个函数实现信号的安装：signal()、sigaction()。其中signal()在可靠信号系统调用的基础上实现, 是库函数。它只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。

(5) 信号的屏蔽

所谓屏蔽, 并不是禁止递送信号，而是暂时阻塞信号的递送，解除屏蔽后，信号将被递送，不会丢失。相关API为：

int sigemptyset(sigset_t *set);
int sigfillset(sigset_t *set);
int sigaddset(sigset_t *set, int signum);
int sigdelset(sigset_t *set, int signum);
int sigismember(const sigset_t *set, int signum);
int sigsuspend(const sigset_t *mask);
int sigpending(sigset_t *set);
int sigprocmask(int how, const sigset_t *set, sigset_t *oldset))；

sigprocmask()函数能够根据参数how来实现对信号集的操作，操作主要有三种：

SIG_BLOCK 在进程当前阻塞信号集中添加set指向信号集中的信号
SIG_UNBLOCK 如果进程阻塞信号集中包含set指向信号集中的信号，则解除对该信号的阻塞。
SIG_SETMASK 更新进程阻塞信号集为set指向的信号集，屏蔽整个进程的信号

(6) 信号的生命周期

信号的生命周期是指从信号发送到信号处理函数的执行完毕。对于一个完整的信号生命周期(从信号发送到相应的处理函数执行完毕)来说，可以分为三个重要的阶段，这三个阶段由四个重要事件来刻画：信号诞生；信号在进程中注册完毕；信号在进程中的注销完毕；信号处理函数执行完毕。

a、信号的诞生

信号的诞生指的是触发信号的事件发生（如检测到硬件异常、定时器超时以及调用信号发送函kill()或sigqueue()等）。

b、信号在目标进程中"注册"

进程的task_struct结构中有关于本进程中未决信号的数据成员：

struct sigpending pending：

struct sigpending{
    struct sigqueue *head, **tail;
    sigset_t signal;
};

第三个成员是进程中所有未决信号集，第一、第二个成员分别指向一个sigqueue类型的结构链（称之为"未决信号链表"）的首尾，链表中的每个sigqueue结构刻画一个特定信号所携带的信息，并指向下一个sigqueue结构：

struct sigqueue{
    struct sigqueue *next;
    siginfo_t info;
}

信号在进程中注册指的就是信号值加入到进程的未决信号集中（sigpending结构的第二个成员sigset_t signal），并且加入未决信号链表的末尾。只要信号在进程的未决信号集中，表明进程已经知道这些信号的存在，但还没来得及处理，或者该信号被进程阻塞。当一个实时信号发送给一个进程时，不管该信号是否已经在进程中注册，都会被再注册一次，因此，信号不会丢失，因此，实时信号又叫做"可靠信号"。这意味着同一个实时信号可以在同一个进程的未决信号链表中添加多次。当一个非实时信号发送给一个进程时，如果该信号已经在进程中注册，则该信号将被丢弃，造成信号丢失。因此，非实时信号又叫做"不可靠信号"。这意味着同一个非实时信号在进程的未决信号链表中，至多占有一个sigqueue结构。一个非实时信号诞生后，（1）如果发现相同的信号已经在目标结构中注册，则不再注册，对于进程来说，相当于不知道本次信号发生，信号丢失。（2）如果进程的未决信号中没有相同信号，则在进程中注册自己。

c、信号的注销

在进程执行过程中，会检测是否有信号等待处理（每次从系统空间返回到用户空间时都做这样的检查）。如果存在未决信号等待处理且该信号没有被进程阻塞，则在运行相应的信号处理函数前，进程会把信号在未决信号链中占有的结构卸掉。是否将信号从进程未决信号集中删除对于实时与非实时信号是不同的。对于非实时信号来说，由于在未决信号信息链中最多只占用一个sigqueue结构，因此该结构被释放后，应该把信号在进程未决信号集中删除（信号注销完毕）；而对于实时信号来说，可能在未决信号信息链中占用多个sigqueue结构，因此应该针对占用sigqueue结构的数目区别对待：如果只占用一个sigqueue结构（进程只收到该信号一次），则应该把信号在进程的未决信号集中删除（信号注销完毕）。否则，不应该在进程的未决信号集中删除该信号（信号注销完毕）。进程在执行信号相应处理函数之前，首先要把信号在进程中注销。

d、信号的生命终止

进程注销信号后，立即执行相应的信号处理函数，执行完毕后，信号的本次发送对进程的影响彻底结束。

3、报文(Message)队列（消息队列）

(1) 消息队列的概念

消息队列是消息的链接表，包括Posix消息队列、system V消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺点。消息队列是随内核持续的。

每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息，包括消息队列键值、用户ID、组ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。读者可以访问这些信息，也可以设置其中的某些信息。

结构 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_cbytes;     // 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 on queue, unused
    __kernel_time_t msg_stime;     // last msgsnd time
    __kernel_time_t msg_stime;     // last msgrcv time   
    __kernel_time_t msg_stime;     // last change time
    unsigned long msg_lcbytes;     // Reuse junk fields for 32bit
    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_cbytes;     // 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
}

(2) 消息队列与内核的联系

从上图可以看出，全局数据结构 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;
}

(3) 消息队列的操作

a、打开或创建消息队列

消息队列的内核持续性要求每个消息队列都在系统范围内对应唯一的键值，所以，要获得一个消息队列的描述字，只需提供该消息队列的键值即可；

注：消息队列描述字是由在系统范围内唯一的键值生成的，而键值可以看作对应系统内的一条路经。

b、读写的操作

消息读写操作非常简单，对开发人员来说，每个消息都类似如下的数据结构：

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

mtype成员代表消息类型，从消息队列中读取消息的一个重要依据就是消息的类型；mtext是消息内容，当然长度不一定为1。因此，对于发送消息来说，首先预置一个msgbuf缓冲区并写入消息类型和内容，调用相应的发送函数即可；对读取消息来说，首先分配这样一个msgbuf缓冲区，然后把消息读入该缓冲区即可。

c、获得或设置消息队列属性

消息队列的信息基本上都保存在消息队列头中，因此，可以分配一个类似于消息队列头的结构，来返回消息队列的属性；同样可以设置该数据结构。

(4) 消息队列与命名管道的比较

消息队列跟命名管道有不少的相同之处，通过与命名管道一样，消息队列进行通信的进程可以是不相关的进程，同时它们都是通过发送和接收的方式来传递数据的。在命名管道中，发送数据用write，接收数据用read，则在消息队列中，发送数据用msgsnd，接收数据用msgrcv。而且它们对每个数据都有一个最大长度的限制。

与命名管道相比，消息队列的优势在于：

消息队列也可以独立于发送和接收进程而存在，从而消除了在同步命名管道的打开和关闭时可能产生的困难。
同时通过发送消息还可以避免命名管道的同步和阻塞问题，不需要由进程自己来提供同步方法。
接收程序可以通过消息类型有选择地接收数据，而不是像命名管道中那样，只能默认地接收。

4、共享内存

共享内存是在多个进程之间共享内存区域的一种进程间的通信方式，由IPC为进程创建的一个特殊地址范围，它将出现在该进程的地址空间中。其他进程可以将同一段共享内存连接到自己的地址空间中。所有进程都可以访问共享内存中的地址，就好像它们是malloc分配的一样。如果一个进程向共享内存中写入了数据，所做的改动将立刻被其他进程看到。

共享内存是IPC最快捷的方式，因为共享内存方式的通信没有中间过程，而管道、消息队列等方式则是需要将数据通过中间机制进行转换。共享内存方式直接将某段内存段进行映射，多个进程间的共享内存是同一块的物理空间，仅仅映射到各进程的地址不同而已，因此不需要进行复制，可以直接使用此段空间。

注意：共享内存本身并没有同步机制，需要程序员自己控制。

得到共享内存有两种方式：映射/dev/mem设备和内存映像文件。前一种方式不给系统带来额外的开销，但在现实中并不常用，因为它控制存取的将是实际的物理内存，在Linux系统下，这只有通过限制Linux系统存取的内存才可以做到，这当然不太实际。常用的方式是通过shmXXX函数族来实现利用共享内存进行存储的。

(1) 共享内存原理

进程间需要共享的数据被放在一个叫做IPC共享内存区域的地方，所有需要访问该共享区域的进程都要把该共享区域映射到本进程的地址空间中去。系统V共享内存通过shmget获得或创建一个IPC共享内存区域，并返回相应的标识符。内核在保证shmget获得或创建一个共享内存区，初始化该共享内存区相应的shmid_kernel结构体的同时，还将在特殊文件系统shm中，创建并打开一个同名文件，并在内存中建立起该文件的相应dentry及inode结构，新打开的文件不属于任何一个进程（任何进程都可以访问该共享内存区）。所有这一切都是系统调用shmget完成的。

(2) 共享内存 API

int shmget(key_t key, int size, int flag);

shmget()用来获得共享内存区域的ID，如果不存在指定的共享区域就创建相应的区域。这个函数有点类似大家熟悉的malloc函数，系统按照请求分配size大小的内存用作共享内存。Linux系统内核中每个IPC结构都有的一个非负整数的标识符，这样对一个消息队列发送消息时只要引用标识符就可以了。这个标识符是内核由IPC结构的关键字得到的，这个关键字，就是上面第一个函数的 key。数据类型key_t是在头文件sys/types.h中定义的，它是一个长整形的数据。在我们后面的章节中，还会碰到这个关键字。

void *shmat(int shmid, void *addr, int flag);

shmat()把共享内存区域映射到调用进程的地址空间中去，这样，进程就可以方便地对共享区域进行访问操作。shmid为shmget函数返回的共享存储标识符，addr和flag参数决定了以什么方式来确定连接的地址，函数的返回值即是该进程数据段所连接的实际地址，进程可以对此进程进行读写操作。

int shmdt(const void *shm_addr);

shmdt()调用用来解除进程对共享内存区域的映射。将共享内存从当前进程中分离，参数为共享内存映射的地址。

int shmctl(int shm_id,int cmd,struct shmid_ds *buf);

shmctl实现对共享内存区域的控制操作。shmctl函数是控制函数，使用方法和消息队列msgctl()函数调用完全类似。参数一shm_id是共享内存的句柄，cmd是向共享内存发送的命令，最后一个参数buf是向共享内存发送命令的参数。

使用共享存储来实现进程间通信的注意点是对数据存取的同步，必须确保当一个进程去读取数据时，它所想要的数据已经写好了。通常，信号量被要来实现对共享存储数据存取的同步，另外，可以通过使用shmctl函数设置共享存储内存的某些标志位如SHM_LOCK、SHM_UNLOCK等来实现。

5、信号量（semaphore）

(1) 信号量的概念

为了防止出现因多个程序同时访问一个共享资源而引发的一系列问题，我们需要一种方法。比如在任一时刻只能有一个执行线程访问代码的临界区域。临界区域是指执行数据更新的代码需要独占式地执行。而信号量就可以提供这样的一种访问机制，让一个临界区同一时间只有一个线程在访问它，也就是说信号量是用来调协进程对共享资源的访问的。

信号量是一个特殊的变量，程序对其访问都是原子操作，且只允许对它进行等待（即P(信号变量))和发送（即V(信号变量))信息操作。最简单的信号量是只能取0和1的变量，这也是信号量最常见的一种形式，叫做二进制信号量。而可以取多个正整数的信号量被称为通用信号量。

(2) 信号量的工作原理

由于信号量只能进行两种操作等待和发送信号，即P(sv)和V(sv)，他们的行为是这样的：

P(sv)：如果sv的值大于零，就给它减1；如果它的值为零，就挂起该进程的执行
V(sv)：如果有其他进程因等待sv而被挂起，就让它恢复运行，如果没有进程因等待sv而挂起，就给它加1

举个例子，就是两个进程共享信号量sv，一旦其中一个进程执行了P(sv)操作，它将得到信号量，并可以进入临界区，使sv减1。而第二个进程将被阻止进入临界区，因为当它试图执行P(sv)时，sv为0，它会被挂起以等待第一个进程离开临界区域并执行V(sv)释放信号量，这时第二个进程就可以恢复执行。

信号量又称为信号灯，它是用来协调不同进程间的数据对象的，而最主要的应用是前一节的共享内存方式的进程间通信。本质上，信号量是一个计数器，它用来记录对某个资源（如共享内存）的存取状况。一般说来，为了获得共享资源，进程需要执行下列操作：

测试控制该资源的信号量。
若此信号量的值为正，则允许进行使用该资源。进程将信号量减1。
若此信号量为0，则该资源目前不可用，进程进入睡眠状态，直至信号量值大于0，进程被唤醒，转入步骤（1）。
当进程不再使用一个信号量控制的资源时，信号量值加1。如果此时有进程正在睡眠等待此信号量，则唤醒此进程。

(3) 信号量API

Linux提供了一组精心设计的信号量接口来对信号进行操作，它们不只是针对二进制信号量，下面将会对这些函数进行介绍，但请注意，这些函数都是用来对成组的信号量值进行操作的。它们声明在头文件sys/sem.h中。

维护信号量状态的是Linux内核操作系统而不是用户进程。我们可以从头文件/usr/src/linux/include /linux /sem.h 中看到内核用来维护信号量状态的各个结构的定义。信号量是一个数据集合，用户可以单独使用这一集合的每个元素。

struct sem {
    short sempid;      // pid of last operaton
    ushort semval;     // current value
    ushort semncnt;    // num procs awaiting increase in semval
    ushort semzcnt;    // num procs awaiting semval = 0
}

int semget(key_t key, int num_sems, int sem_flags);

它的作用是创建一个新信号量或取得一个已有信号量，semget函数成功返回一个相应信号标识符（非零），失败返回-1。

第一个参数key是整数值（唯一非零），不相关的进程可以通过它访问一个信号量，它代表程序可能要使用的某个资源，程序对所有信号量的访问都是间接的，程序先通过调用semget函数并提供一个键，再由系统生成一个相应的信号标识符（semget函数的返回值），只有semget函数才直接使用信号量键，所有其他的信号量函数使用由semget函数返回的信号量标识符。如果多个程序使用相同的key值，key将负责协调工作。

第二个参数num_sems指定需要的信号量数目，它的值几乎总是1。如果是创建新集合（一般在服务器中），则必须指定nsems；如果是引用一个现有的信号量集合（一般在客户机中）则将nsems指定为0。

第三个参数sem_flags是一组标志，决定是创建新的信号量集合，还是引用一个现有的信号量集合。当想要当信号量不存在时创建一个新的信号量，可以和值IPC_CREAT做按位或操作。设置了IPC_CREAT标志后，即使给出的键是一个已有信号量的键，也不会产生错误。而IPC_CREAT | IPC_EXCL则可以创建一个新的，唯一的信号量，如果信号量已存在，返回一个错误。

int semop(int sem_id, struct sembuf *sem_opa, size_t num_sem_ops);

它的作用是改变信号量的值，sem_id是由semget返回的信号量标识符，sembuf结构的定义如下：

struct sembuf{
    short sem_num; // 除非使用一组信号量，否则为0
    short sem_op;  // 信号量在一次操作中需要改变的数据，通常是两个数，一个是-1，即P(等待)操作，另一个是+1，即V(发送信号)操作。
    short sem_flg; // 通常为SEM_UNDO，使操作系统跟踪信号，并在进程没有释放该信号量而终止时，操作系统释放信号量
}

int semctl(int sem_id, int sem_num, int command, ...);

如果有第四个参数，它通常是一个union semum结构，定义如下：

union semun{
    int val;
    struct semid_ds *buf;
    unsigned short *array;
}

前两个参数与前面一个函数中的一样，command通常是下面两个值中的其中一个

SETVAL：用来把信号量初始化为一个已知的值。p 这个值通过union semun中的val成员设置，其作用是在信号量第一次使用前对它进行设置。

IPC_RMID：用于删除一个已经无需继续使用的信号量标识符。

6、套接字（Socket）

socket API原本是为网络通讯设计的，但后来在socket的框架上发展出一种IPC机制，就是UNIX Domain Socket。虽然网络socket也可用于同一台主机的进程间通讯（通过loopback地址127.0.0.1），但是UNIX Domain Socket用于IPC更有效率：不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用层数据从一个进程拷贝到另一个进程。UNIX域套接字与TCP套接字相比较，在同一台传输主机的速度前者是后者的两倍。这是因为，IPC机制本质上是可靠的通讯，而网络协议是为不可靠的通讯设计的。UNIX Domain Socket也提供面向流和面向数据包两种API接口，类似于TCP和UDP，但是面向消息的UNIX Domain Socket也是可靠的，消息既不会丢失也不会顺序错乱。值得注意的是，Unix域协议表示协议地址的是路径名，而不是Internet域的IP地址和端口号。

套接字机制不但可以单机的不同进程通信，而且使得跨网机器间进程可以通信。套接字的创建和使用与管道是有区别的，套接字明确地将客户端与服务器区分开来，可以实现多个客户端连到同一服务器。

服务器套接字连接过程描述：

首先，服务器应用程序用socket创建一个套接字，它是系统分配服务器进程的类似文件描述符的资源。接着，服务器调用bind给套接字命名。这个名字是一个标示符，它允许linux将进入的针对特定端口的连接转到正确的服务器进程。然后，系统调用listen函数开始接听，等待客户端连接。listen创建一个队列并将其用于存放来自客户端的进入连接。当客户端调用connect请求连接时，服务器调用accept接受客户端连接，accept此时会创建一个新套接字，用于与这个客户端进行通信。

客户端套接字连接过程描述：

客户端首先调用socket创建一个未命名套接字，让后将服务器的命名套接字作为地址来调用connect与服务器建立连接。

只要双方连接建立成功，我们就可以像操作底层文件一样来操作socket套接字实现通信。

(1) Socket 相关概念

两个基本概念：客户方和服务方。当两个应用之间需要采用SOCKET通信时，首先需要在两个应用之间（可能位于同一台机器，也可能位于不同的机器）建立SOCKET连接。

发起呼叫连接请求的一方为客户方

在客户方呼叫连接请求之前，它必须知道服务方在哪里。所以需要知道服务方所在机器的IP地址或机器名称，如果客户方和服务方事前有一个约定就好了，这个约定就是PORT（端口号）。也就是说，客户方可以通过服务方所在机器的IP地址或机器名称和端口号唯一的确定方式来呼叫服务方。

接受呼叫连接请求的一方成为服务方

在客户方呼叫之前，服务方必须处于侦听状态，侦听是否有客户要求建立连接。一旦接到连接请求，服务方可以根据情况建立或拒绝连接。当客户方的消息到达服务方端口时，会自动触发一个事件（event），服务方只要接管该事件，就可以接受来自客户方的消息了。