Linux环境进程间通信信号灯.docx

Linux环境进程间通信信号灯.docx

《Linux环境进程间通信信号灯.docx》由会员分享，可在线阅读，更多相关《Linux环境进程间通信信号灯.docx（16页珍藏版）》请在冰豆网上搜索。

Linux环境进程间通信信号灯

Linux环境进程间通信-信号灯（四）

信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。

相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。

除了用于访问控制外，还可用于进程同步。

一、信号灯概述

信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。

相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。

除了用于访问控制外，还可用于进程同步。

信号灯有以下两种类型：

∙二值信号灯：

最简单的信号灯形式，信号灯的值只能取0或1，类似于互斥锁。

注：

二值信号灯能够实现互斥锁的功能，但两者的关注内容不同。

信号灯强调共享资源，只要共享资源可用，其他进程同样可以修改信号灯的值；互斥锁更强调进程，占用资源的进程使用完资源后，必须由进程本身来解锁。

∙计算信号灯：

信号灯的值可以取任意非负值（当然受内核本身的约束）。

回页首

二、Linux信号灯

linux对信号灯的支持状况与消息队列一样，在redhad8.0发行版本中支持的是系统V的信号灯。

因此，本文将主要介绍系统V信号灯及其相应API。

在没有声明的情况下，以下讨论中指的都是系统V信号灯。

注意，通常所说的系统V信号灯指的是计数信号灯集。

回页首

三、信号灯与内核

1、系统V信号灯是随内核持续的，只有在内核重起或者显示删除一个信号灯集时，该信号灯集才会真正被删除。

因此系统中记录信号灯的数据结构（structipc_idssem_ids）位于内核中，系统中的所有信号灯都可以在结构sem_ids中找到访问入口。

2、下图说明了内核与信号灯是怎样建立起联系的：

其中：

structipc_idssem_ids是内核中记录信号灯的全局数据结构；描述一个具体的信号灯及其相关信息。

其中，structsem结构如下：

structsem{

intsemval;//currentvalue

intsempid//pidoflastoperation

}

从上图可以看出，全局数据结构structipc_idssem_ids可以访问到structkern_ipc_perm的第一个成员：

structkern_ipc_perm；而每个structkern_ipc_perm能够与具体的信号灯对应起来是因为在该结构中，有一个key_t类型成员key，而key则唯一确定一个信号灯集；同时，结构structkern_ipc_perm的最后一个成员sem_nsems确定了该信号灯在信号灯集中的顺序，这样内核就能够记录每个信号灯的信息了。

kern_ipc_perm结构参见《Linux环境进程间通信（三）：

消息队列》。

structsem_array见附录1。

回页首

四、操作信号灯

对消息队列的操作无非有下面三种类型：

1、打开或创建信号灯

与消息队列的创建及打开基本相同，不再详述。

2、信号灯值操作

linux可以增加或减小信号灯的值，相应于对共享资源的释放和占有。

具体参见后面的semop系统调用。

3、获得或设置信号灯属性：

系统中的每一个信号灯集都对应一个structsem_array结构，该结构记录了信号灯集的各种信息，存在于系统空间。

为了设置、获得该信号灯集的各种信息及属性，在用户空间有一个重要的联合结构与之对应，即unionsemun。

联合semun数据结构各成员意义参见附录2

信号灯API

1、文件名到键值

#include

#include

key_tftok（char*pathname,charproj）；

它返回与路径pathname相对应的一个键值，具体用法请参考《Linux环境进程间通信（三）：

消息队列》。

2、linux特有的ipc（）调用：

intipc（unsignedintcall,intfirst,intsecond,intthird,void*ptr,longfifth）;

参数call取不同值时，对应信号灯的三个系统调用：

当call为SEMOP时，对应intsemop（intsemid,structsembuf*sops,unsignednsops）调用；

当call为SEMGET时，对应intsemget（key_tkey,intnsems,intsemflg）调用；

当call为SEMCTL时，对应intsemctl（intsemid，intsemnum，intcmd，unionsemunarg）调用；

这些调用将在后面阐述。

注：

本人不主张采用系统调用ipc（），而更倾向于采用系统V或者POSIX进程间通信API。

原因已在Linux环境进程间通信（三）：

消息队列中给出。

3、系统V信号灯API

系统V消息队列API只有三个，使用时需要包括几个头文件：

#include

#include

#include

1）intsemget（key_tkey,intnsems,intsemflg）

参数key是一个键值，由ftok获得，唯一标识一个信号灯集，用法与msgget（）中的key相同；参数nsems指定打开或者新创建的信号灯集中将包含信号灯的数目；semflg参数是一些标志位。

参数key和semflg的取值，以及何时打开已有信号灯集或者创建一个新的信号灯集与msgget（）中的对应部分相同，不再祥述。

该调用返回与健值key相对应的信号灯集描述字。

调用返回：

成功返回信号灯集描述字，否则返回-1。

注：

如果key所代表的信号灯已经存在，且semget指定了IPC_CREAT|IPC_EXCL标志，那么即使参数nsems与原来信号灯的数目不等，返回的也是EEXIST错误；如果semget只指定了IPC_CREAT标志，那么参数nsems必须与原来的值一致，在后面程序实例中还要进一步说明。

2）intsemop（intsemid,structsembuf*sops,unsignednsops）;

semid是信号灯集ID，sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的操作。

nsops为sops指向数组的大小。

sembuf结构如下：

structsembuf{

unsignedshortsem_num;/*semaphoreindexinarray*/

shortsem_op;/*semaphoreoperation*/

shortsem_flg;/*operationflags*/

};

sem_num对应信号集中的信号灯，0对应第一个信号灯。

sem_flg可取IPC_NOWAIT以及SEM_UNDO两个标志。

如果设置了SEM_UNDO标志，那么在进程结束时，相应的操作将被取消，这是比较重要的一个标志位。

如果设置了该标志位，那么在进程没有释放共享资源就退出时，内核将代为释放。

如果为一个信号灯设置了该标志，内核都要分配一个sem_undo结构来记录它，为的是确保以后资源能够安全释放。

事实上，如果进程退出了，那么它所占用就释放了，但信号灯值却没有改变，此时，信号灯值反映的已经不是资源占有的实际情况，在这种情况下，问题的解决就靠内核来完成。

这有点像僵尸进程，进程虽然退出了，资源也都释放了，但内核进程表中仍然有它的记录，此时就需要父进程调用waitpid来解决问题了。

sem_op的值大于0，等于0以及小于0确定了对sem_num指定的信号灯进行的三种操作。

具体请参考linux相应手册页。

这里需要强调的是semop同时操作多个信号灯，在实际应用中，对应多种资源的申请或释放。

semop保证操作的原子性，这一点尤为重要。

尤其对于多种资源的申请来说，要么一次性获得所有资源，要么放弃申请，要么在不占有任何资源情况下继续等待，这样，一方面避免了资源的浪费；另一方面，避免了进程之间由于申请共享资源造成死锁。

也许从实际含义上更好理解这些操作：

信号灯的当前值记录相应资源目前可用数目；sem_op>0对应相应进程要释放sem_op数目的共享资源；sem_op=0可以用于对共享资源是否已用完的测试；sem_op<0相当于进程要申请-sem_op个共享资源。

再联想操作的原子性，更不难理解该系统调用何时正常返回，何时睡眠等待。

调用返回：

成功返回0，否则返回-1。

3）intsemctl（intsemid，intsemnum，intcmd，unionsemunarg）

该系统调用实现对信号灯的各种控制操作，参数semid指定信号灯集，参数cmd指定具体的操作类型；参数semnum指定对哪个信号灯操作，只对几个特殊的cmd操作有意义；arg用于设置或返回信号灯信息。

该系统调用详细信息请参见其手册页，这里只给出参数cmd所能指定的操作。

IPC_STAT

获取信号灯信息，信息由arg.buf返回；

IPC_SET

设置信号灯信息，待设置信息保存在arg.buf中（在manpage中给出了可以设置哪些信息）；

GETALL

返回所有信号灯的值，结果保存在arg.array中，参数sennum被忽略；

GETNCNT

返回等待semnum所代表信号灯的值增加的进程数，相当于目前有多少进程在等待semnum代表的信号灯所代表的共享资源；

GETPID

返回最后一个对semnum所代表信号灯执行semop操作的进程ID；

GETVAL

返回semnum所代表信号灯的值；

GETZCNT

返回等待semnum所代表信号灯的值变成0的进程数；

SETALL

通过arg.array更新所有信号灯的值；同时，更新与本信号集相关的semid_ds结构的sem_ctime成员；

SETVAL

设置semnum所代表信号灯的值为arg.val；

调用返回：

调用失败返回-1，成功返回与cmd相关：

Cmd

returnvalue

GETNCNT

Semncnt

GETPID

Sempid

GETVAL

Semval

GETZCNT

Semzcnt

回页首

五、信号灯的限制

1、一次系统调用semop可同时操作的信号灯数目SEMOPM，semop中的参数nsops如果超过了这个数目，将返回E2BIG错误。

SEMOPM的大小特定与系统，redhat8.0为32。

2、信号灯的最大数目：

SEMVMX，当设置信号灯值超过这个限制时，会返回ERANGE错误。

在redhat8.0中该值为32767。

3、系统范围内信号灯集的最大数目SEMMNI以及系统范围内信号灯的最大数目SEMMNS。

超过这两个限制将返回ENOSPC错误。

redhat8.0中该值为32000。

4、每个信号灯集中的最大信号灯数目SEMMSL，redhat8.0中为250。

SEMOPM以及SEMVMX是使用semop调用时应该注意的；SEMMNI以及SEMMNS是调用semget时应该注意的。

SEMVMX同时也是semctl调用应该注意的。

回页首