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

http://www.ibm.com/developerworks/cn/linux/l-ipc/part4/

一、信号灯概述

信号灯与其他进程间通信方式不大相同，它主要提供对进程间共享资源访问控制机制。相当于内存中的标志，进程可以根据它判定是否能够访问某些共享资源，同时，进程也可以修改该标志。除了用于访问控制外，还可用于进程同步。信号灯有以下两种类型：

• 二值信号灯：最简单的信号灯形式，信号灯的值只能取0或1，类似于互斥锁。 
  注：二值信号灯能够实现互斥锁的功能，但两者的关注内容不同。信号灯强调共享资源，只要共享资源可用，其他进程同样可以修改信号灯的值；互斥锁更强调进程，占用资源的进程使用完资源后，必须由进程本身来解锁。
• 计算信号灯：信号灯的值可以取任意非负值（当然受内核本身的约束）。

 

回页首

二、Linux信号灯

linux对信号灯的支持状况与消息队列一样，在red had 8.0发行版本中支持的是系统V的信号灯。因此，本文将主要介绍系统V信号灯及其相应API。在没有声明的情况下，以下讨论中指的都是系统V信号灯。

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

 

回页首

三、信号灯与内核

1、系统V信号灯是随内核持续的，只有在内核重起或者显示删除一个信号灯集时，该信号灯集才会真正被删除。因此系统中记录信号灯的数据结构（struct ipc_ids sem_ids）位于内核中，系统中的所有信号灯都可以在结构sem_ids中找到访问入口。

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

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

其中，struct sem结构如下：

struct sem{
int semval;		// current value
int sempid		// pid of last operation
}

从上图可以看出，全局数据结构struct ipc_ids sem_ids可以访问到struct kern_ipc_perm的第一个成员：struct kern_ipc_perm；而每个struct kern_ipc_perm能够与具体的信号灯对应起来是因为在该结构中，有一个key_t类型成员key，而key则唯一确定一个信号灯集；同时，结构struct kern_ipc_perm的最后一个成员sem_nsems确定了该信号灯在信号灯集中的顺序，这样内核就能够记录每个信号灯的信息了。kern_ipc_perm结构参见《Linux环境进程间通信（三）：消息队列》。struct sem_array见附录1。

 

回页首

四、操作信号灯

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

1、 打开或创建信号灯 
与消息队列的创建及打开基本相同，不再详述。

2、 信号灯值操作 
linux可以增加或减小信号灯的值，相应于对共享资源的释放和占有。具体参见后面的semop系统调用。

3、 获得或设置信号灯属性： 
系统中的每一个信号灯集都对应一个struct sem_array结构，该结构记录了信号灯集的各种信息，存在于系统空间。为了设置、获得该信号灯集的各种信息及属性，在用户空间有一个重要的联合结构与之对应，即union semun。

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

信号灯API

1、文件名到键值

#include <sys/types.h>
#include <sys/ipc.h>
key_t ftok (char*pathname, char proj)；

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

2、 linux特有的ipc()调用：

int ipc(unsigned int call, int first, int second, int third, void *ptr, long fifth);

参数call取不同值时，对应信号灯的三个系统调用： 
当call为SEMOP时，对应int semop(int semid, struct sembuf *sops, unsigned nsops)调用； 
当call为SEMGET时，对应int semget(key_t key, int nsems, int semflg)调用； 
当call为SEMCTL时，对应int semctl(int semid，int semnum，int cmd，union semun arg)调用； 
这些调用将在后面阐述。

注：本人不主张采用系统调用ipc()，而更倾向于采用系统V或者POSIX进程间通信API。原因已在Linux环境进程间通信（三）：消息队列中给出。

3、系统V信号灯API

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

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

1）int semget(key_t key, int nsems, int semflg) 
参数key是一个键值，由ftok获得，唯一标识一个信号灯集，用法与msgget()中的key相同；参数nsems指定打开或者新创建的信号灯集中将包含信号灯的数目；semflg参数是一些标志位。参数key和semflg的取值，以及何时打开已有信号灯集或者创建一个新的信号灯集与msgget()中的对应部分相同，不再祥述。 
该调用返回与健值key相对应的信号灯集描述字。 
调用返回：成功返回信号灯集描述字，否则返回-1。 
注：如果key所代表的信号灯已经存在，且semget指定了IPC_CREAT|IPC_EXCL标志，那么即使参数nsems与原来信号灯的数目不等，返回的也是EEXIST错误；如果semget只指定了IPC_CREAT标志，那么参数nsems必须与原来的值一致，在后面程序实例中还要进一步说明。

2）int semop(int semid, struct sembuf *sops, unsigned nsops); 
semid是信号灯集ID，sops指向数组的每一个sembuf结构都刻画一个在特定信号灯上的操作。nsops为sops指向数组的大小。 
sembuf结构如下：

struct sembuf {
	unsigned short  	sem_num;		/* semaphore index in array */
	short			sem_op;		/* semaphore operation */
	short			sem_flg;		/* operation flags */
};

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) int semctl(int semid，int semnum，int cmd，union semun arg) 
该系统调用实现对信号灯的各种控制操作，参数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	return value
GETNCNT	Semncnt
GETPID	Sempid
GETVAL	Semval
GETZCNT	Semzcnt

 

回页首

五、信号灯的限制

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

2、 信号灯的最大数目：SEMVMX，当设置信号灯值超过这个限制时，会返回ERANGE错误。在redhat 8.0中该值为32767。

3、 系统范围内信号灯集的最大数目SEMMNI以及系统范围内信号灯的最大数目SEMMNS。超过这两个限制将返回ENOSPC错误。redhat 8.0中该值为32000。

4、 每个信号灯集中的最大信号灯数目SEMMSL，redhat 8.0中为250。 SEMOPM以及SEMVMX是使用semop调用时应该注意的；SEMMNI以及SEMMNS是调用semget时应该注意的。SEMVMX同时也是semctl调用应该注意的。

 

回页首

六、竞争问题

第一个创建信号灯的进程同时也初始化信号灯，这样，系统调用semget包含了两个步骤：创建信号灯；初始化信号灯。由此可能导致一种竞争状态：第一个创建信号灯的进程在初始化信号灯时，第二个进程又调用semget，并且发现信号灯已经存在，此时，第二个进程必须具有判断是否有进程正在对信号灯进行初始化的能力。在参考文献[1]中，给出了绕过这种竞争状态的方法：当semget创建一个新的信号灯时，信号灯结构semid_ds的sem_otime成员初始化后的值为0。因此，第二个进程在成功调用semget后，可再次以IPC_STAT命令调用semctl，等待sem_otime变为非0值，此时可判断该信号灯已经初始化完毕。下图描述了竞争状态产生及解决方法：

实际上，这种解决方法也是基于这样一个假定：第一个创建信号灯的进程必须调用semop，这样sem_otime才能变为非零值。另外，因为第一个进程可能不调用semop，或者semop操作需要很长时间，第二个进程可能无限期等待下去，或者等待很长时间。

 

回页首

七、信号灯应用实例

本实例有两个目的：1、获取各种信号灯信息；2、利用信号灯实现共享资源的申请和释放。并在程序中给出了详细注释。

#include <linux/sem.h>
#include <stdio.h>
#include <errno.h>
#define SEM_PATH "/unix/my_sem"
#define max_tries 3
int semid;
main()
{
int flag1,flag2,key,i,init_ok,tmperrno;
struct semid_ds sem_info;
struct seminfo sem_info2;
union semun arg;       //union semun： 请参考附录2
struct sembuf askfor_res, free_res;
flag1=IPC_CREAT|IPC_EXCL|00666;
flag2=IPC_CREAT|00666;
key=ftok(SEM_PATH,'a');
//error handling for ftok here;
init_ok=0;
semid=semget(key,1,flag1);
//create a semaphore set that only includes one semphore.
if(semid<0)
{
  tmperrno=errno;
  perror("semget");
if(tmperrno==EEXIST)
//errno is undefined after a successful library call( including perror call)
//so it is saved  in tmperrno.
    {
    semid=semget(key,1,flag2);
//flag2 只包含了IPC_CREAT标志, 参数nsems(这里为1)必须与原来的信号灯数目一致
    arg.buf=&sem_info;
    for(i=0; i<max_tries; i++)
    {
      if(semctl(semid, 0, IPC_STAT, arg)==-1)
      {  perror("semctl error"); i=max_tries;}
      else
      {
        if(arg.buf->sem_otime!=0){ i=max_tries;  init_ok=1;}
        else   sleep(1);
      }
    }
    if(!init_ok)
  // do some initializing, here we assume that the first process that creates the sem
  //  will finish initialize the sem and run semop in max_tries*1 seconds. else it will
  // not run semop any more.
    {
      arg.val=1;
      if(semctl(semid,0,SETVAL,arg)==-1) perror("semctl setval error");
    }
  }
  else
  {perror("semget error, process exit");  exit();  }
}
else //semid>=0; do some initializing
{
  arg.val=1;
  if(semctl(semid,0,SETVAL,arg)==-1)
    perror("semctl setval error");
}
//get some information about the semaphore and the limit of semaphore in redhat8.0
  arg.buf=&sem_info;
  if(semctl(semid, 0, IPC_STAT, arg)==-1)
    perror("semctl IPC STAT");
  printf("owner's uid is %d\n",   arg.buf->sem_perm.uid);
  printf("owner's gid is %d\n",   arg.buf->sem_perm.gid);
  printf("creater's uid is %d\n",   arg.buf->sem_perm.cuid);
  printf("creater's gid is %d\n",   arg.buf->sem_perm.cgid);
  arg.__buf=&sem_info2;
  if(semctl(semid,0,IPC_INFO,arg)==-1)
    perror("semctl IPC_INFO");
  printf("the number of entries in semaphore map is %d \n",  arg.__buf->semmap);
  printf("max number of semaphore identifiers is %d \n",    arg.__buf->semmni);
  printf("mas number of semaphores in system is %d \n",   arg.__buf->semmns);
  printf("the number of undo structures system wide is %d \n",  arg.__buf->semmnu);
  printf("max number of semaphores per semid is %d \n",   arg.__buf->semmsl);
  printf("max number of ops per semop call is %d \n",  arg.__buf->semopm);
  printf("max number of undo entries per process is %d \n",  arg.__buf->semume);
  printf("the sizeof of struct sem_undo is %d \n",  arg.__buf->semusz);
  printf("the maximum semaphore value is %d \n",  arg.__buf->semvmx);

//now ask for available resource:
  askfor_res.sem_num=0;
  askfor_res.sem_op=-1;
  askfor_res.sem_flg=SEM_UNDO;    

    if(semop(semid,&askfor_res,1)==-1)//ask for resource
      perror("semop error");

  sleep(3);
  //do some handling on the sharing resource here, just sleep on it 3 seconds
  printf("now free the resource\n");  

//now free resource
  free_res.sem_num=0;
  free_res.sem_op=1;
  free_res.sem_flg=SEM_UNDO;
  if(semop(semid,&free_res,1)==-1)//free the resource.
    if(errno==EIDRM)
      printf("the semaphore set was removed\n");
//you can comment out the codes below to compile a different version:
  if(semctl(semid, 0, IPC_RMID)==-1)
    perror("semctl IPC_RMID");
  else printf("remove sem ok\n");
}

注：读者可以尝试一下注释掉初始化步骤，进程在运行时会出现何种情况（进程在申请资源时会睡眠），同时可以像程序结尾给出的注释那样，把该程序编译成两个不同版本。下面是本程序的运行结果（操作系统redhat8.0）：

owner's uid is 0
owner's gid is 0
creater's uid is 0
creater's gid is 0
the number of entries in semaphore map is 32000
max number of semaphore identifiers is 128
mas number of semaphores in system is 32000
the number of undo structures system wide is 32000
max number of semaphores per semid is 250
max number of ops per semop call is 32
max number of undo entries per process is 32
the sizeof of struct sem_undo is 20
the maximum semaphore value is 32767
now free the resource
remove sem ok

Summary：信号灯与其它进程间通信方式有所不同，它主要用于进程间同步。通常所说的系统V信号灯实际上是一个信号灯的集合，可用于多种共享资源的进程间同步。每个信号灯都有一个值，可以用来表示当前该信号灯代表的共享资源可用（available）数量，如果一个进程要申请共享资源，那么就从信号灯值中减去要申请的数目，如果当前没有足够的可用资源，进程可以睡眠等待，也可以立即返回。当进程要申请多种共享资源时，linux可以保证操作的原子性，即要么申请到所有的共享资源，要么放弃所有资源，这样能够保证多个进程不会造成互锁。Linux对信号灯有各种各样的限制，程序中给出了输出结果。另外，如果读者想对信号灯作进一步的理解，建议阅读sem.h源代码，该文件不长，但给出了信号灯相关的重要数据结构。

附录1： struct sem_array如下：

/*系统中的每个信号灯集对应一个sem_array 结构 */
struct sem_array {
  struct kern_ipc_perm  sem_perm;    /* permissions .. see ipc.h */
  time_t      sem_otime;      /* last semop time */
  time_t      sem_ctime;      /* last change time */
  struct sem    *sem_base;      /* ptr to first semaphore in array */
  struct sem_queue  *sem_pending;    /* pending operations to be processed */
  struct sem_queue  **sem_pending_last;   /* last pending operation */
  struct sem_undo    *undo;      /* undo requests on this array */
  unsigned long    sem_nsems;    /* no. of semaphores in array */
};

其中，sem_queue结构如下：

/* 系统中每个因为信号灯而睡眠的进程，都对应一个sem_queue结构*/
 struct sem_queue {
  struct sem_queue *  next;     /* next entry in the queue */
  struct sem_queue **  prev;
  /* previous entry in the queue, *(q->prev) == q */
  struct task_struct*  sleeper;   /* this process */
  struct sem_undo *  undo;     /* undo structure */
  int   pid;             /* process id of requesting process */
  int   status;           /* completion status of operation */
  struct sem_array *  sma;       /* semaphore array for operations */
  int  id;               /* internal sem id */
  struct sembuf *  sops;       /* array of pending operations */
  int  nsops;             /* number of operations */
  int  alter;             /* operation will alter semaphore */
};

附录2：union semun是系统调用semctl中的重要参数：

union semun {
	int val;					/* value for SETVAL */
	struct semid_ds *buf;		/* buffer for IPC_STAT & IPC_SET */
	unsigned short *array;		/* array for GETALL & SETALL */
	struct seminfo *__buf;		/* buffer for IPC_INFO */   //test!!
	void *__pad;
};
struct  seminfo {
	int semmap;
	int semmni;
	int semmns;
	int semmnu;
	int semmsl;
	int semopm;
	int semume;
	int semusz;
	int semvmx;
	int semaem;
};

参考资料

[1] UNIX网络编程第二卷：进程间通信，作者：W.Richard Stevens，译者：杨继张，清华大学出版社。对POSIX以及系统V信号灯都有阐述，对Linux环境下的程序开发有极大的启发意义。

[2] linux内核源代码情景分析（上），毛德操、胡希明著，浙江大学出版社，给出了系统V信号灯相关的源代码分析，尤其在阐述保证操作原子性方面，以及阐述undo标志位时，讨论的很深刻。

[3]GNU/Linux编程指南，第二版，Kurt Wall等著，张辉译

[4]semget、semop、semctl手册

关于作者

郑彦兴，男，现攻读国防科大计算机学院网络方向博士学位。您可以通过电子邮件 mlinux@163.com和他联系。

对int semop（int semid，struct sembuf *sops，size_t nsops）的百科解释：

背景

信号量的值与相应资源的使用情况有关，当它的值大于 0 时，表示当前可用的资源数的数量；当它的值小于 0 时，其绝对值表示等待使用该资源的进程个数。信号量的值仅能由 PV 操作来改变。

编辑本段定义

在 Linux 下，PV 操作通过调用semop函数来实现。该函数定义在头文件 sys/sem.h中，原型如下：

int semop（int semid，struct sembuf *sops，size_t nsops）；

编辑本段详解

功能描述

操作一个或一组信号。

用法

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

int semop(int semid, struct sembuf *sops, unsigned nsops);

int semtimedop(int semid, struct sembuf *sops, unsigned nsops, struct timespec *timeout);

参数

semid：信号集的识别码，可通过semget获取。

sops：指向存储信号操作结构的数组指针，信号操作结构的原型如下

struct sembuf

{

unsigned short sem_num; /* semaphore number */

short sem_op; /* semaphore operation */

short sem_flg; /* operation flags */

};

这三个字段的意义分别为：

sem_num：操作信号在信号集中的编号，第一个信号的编号是0。

sem_op：如果其值为正数，该值会加到现有的信号内含值中。通常用于释放所控资源的使用权；如果sem_op的值为负数，而其绝对值又大于信号的现值，操作将会阻塞，直到信号值大于或等于sem_op的绝对值。通常用于获取资源的使用权；如果sem_op的值为0，则操作将暂时阻塞，直到信号的值变为0。

sem_flg：信号操作标志，可能的选择有两种

IPC_NOWAIT //对信号的操作不能满足时，semop()不会阻塞，并立即返回，同时设定错误信息。

SEM_UNDO //程序结束时(不论正常或不正常)，保证信号值会被重设为semop()调用前的值。这样做的目的在于避免程序在异常情况下结束时未将锁定的资源解锁，造成该资源永远锁定。

nsops：信号操作结构的数量，恒大于或等于1。

timeout：当semtimedop()调用致使进程进入睡眠时，睡眠时间不能超过本参数指定的值。如果睡眠超时，semtimedop()将失败返回，并设定错误值为EAGAIN。如果本参数的值为NULL，semtimedop()将永远睡眠等待。

返回说明

成功执行时，两个系统调用都返回0。失败返回-1，errno被设为以下的某个值

E2BIG：一次对信号的操作数超出系统的限制

EACCES：调用进程没有权能执行请求的操作，并且不具有CAP_IPC_OWNER权能

EAGAIN：信号操作暂时不能满足，需要重试

EFAULT：sops或timeout指针指向的空间不可访问

EFBIG：sem_num指定的值无效

EIDRM：信号集已被移除

EINTR：系统调用阻塞时，被信号中断

EINVAL：参数无效

ENOMEM：内存不足

ERANGE：信号所允许的值越界

 

对PV操作的百科解释：

PV操作与信号灯的处理相关，P表示通过的意思，V表示释放的意思。

1962年，狄克斯特拉离开数学中心进入位于荷兰南部的艾恩德霍芬技术大学(EindhovenTechnical University）任数学教授。在这里，他参加了X8计算机的开发，设计与实现了具有多道程序运行能力的操作系统——THE Multiprogramming System。THE是艾恩德霍芬技术大学的荷兰文Tchnische Hoogeschool Eindhov –en的词头缩写。狄克斯特拉在THE这个系统中所提出的一系统方法和技术奠定了计算机现代操作系统的基础，尤其是关于多层体系结构，顺序进程之间的同步和互斥机制这样一些重要的思想和概念都是狄克斯特拉在THE中首先提出并为以后的操作系统如UNⅨ等所采用的。为了在单处理机的情况下确定进程（process）能否占有处理机，狄克斯特拉将每个进程分为“就绪”（ready）、“运行”（running）和“阻塞”（blocking）三个工作状态。由于在任一时刻最多只有一个进程可以使用处理机，正占用着处理机的进程称为“运行”进程。当某进程已具备了使用处理机的条件，而当前又没有处理机供其使用，则使该进程处于“就绪”状态。当运行进程由于某种原因无法继续运行下去时，就停止其占用处理机，使之进入“阻塞”状态，待造成其退出运行的条件解除，再进入“就绪”状态。而对系统中所有同时运行的进程，在一个进程访问共享数据时，另一个进程不访问该数据）和互斥（mutually- exclusive，指两个进程不能同时在一个临界区中使用同一个可重复使用的资源，诸如读写缓冲区）两个关系，狄克斯特拉巧妙地利用火车运行控制系统中的“信号灯”（semaphore，或叫”信号量”）概念加以解决。所谓信号灯，实际上就是用来控制进程状态的一个代表某一资源的存储单元。例如，P1和P2是分别将数据送入缓冲B和从缓冲B读出数据的两个进程，为了防止这两个进程并发时产生错误，狄克斯特拉设计了一种同步机制叫“PV操作”，P操作和V操作是执行时不被打断的两个操作系统原语。执行P操作P（S）时信号量S的值减1，若结果小于0，则P（S）执行完毕，否则执行P操作的进程暂停以等待释放。执行V操作V（S）时，S的值加1，若结果不大于0，则释放一个因执行P（S）而等待的进程。对P1和P2可定义两个信号量S1和S2，初值分别为1和0。进程P1在向缓冲B送入数据前执行P操作P（S1），在送入数据后执行V操作V（S2）。进程P2在从缓冲B读取数据前先执行P操作P（S2），在读出数据后执行V操作V（S1）。当P1往缓冲B送入一数据后信号量S1之值变为0，在该数据读出后S1之值才又变为1，因此在前一数未读出前后一数不会送入，从而保证了P1和P2之间的同步。中国读者常常不明白这一同步机制为什么叫PV操作，原来这是狄克斯特拉用荷兰文定义的，因为在荷兰文中，通过叫passeren，释放叫vrijgeven，PV操作因此得名。这是在计算机术语中不是用英语表达的极少数的例子之一。信号量

信号量是最早出现的用来解决进程同步与互斥问题的机制，

包括一个称为信号量的变量及对它进行的两个原语操作。

信号量的概念

1．信号量的类型定义

信号量（semaphore）的数据结构为一个值和一个指针，指针指向等待该信号量的下一个进程。信号量的值与相应资源的使用情况有关。当它的值大于0时，表示当前可用资源的数量；当它的值小于0时，其绝对值表示等待使用该资源的进程个数。注意，信号量的值仅能由PV操作来改变。

一般来说，信号量S>=0时，S表示可用资源的数量。执行一次P操作意味着请求分配一个单位资源，因此S的值减1；当S<0时，表示已经没有可用资源，请求者必须等待别的进程释放该类资源，它才能运行下去。而执行一个V操作意味着释放一个单位资源，因此S的值加1；若S<0，表示有某些进程正在等待该资源，因此要唤醒一个等待状态的进程，使之运行下去。

2．PV原语

PV操作是典型的同步机制之一。用一个信号量与一个消 息联系起来，当信 号量的值为0时，表示期 望的消息尚未产生；当信号 量的值非0时，表示期望的消息已经存在。用P V操作实现进程同步时，调用P操作测试消息是否到达，调用V操作发送消息。

对一个信号量变量可以进行两种原语操作：p操作和v操作，定义如下：procedure p(var s:samephore);

{

s.value=s.value-1;

if (s.value<0) asleep(s.queue);

}

procedure v(var s:samephore);

{

s.value=s.value+1;

if (s.value<=0) wakeup(s.queue);

}

其中用到两个标准过程：

asleep(s.queue）；执行此操作的进程的PCB进入s.queue尾部，进程变成等待状态

wakeup(s.queue）；将s.queue头进程唤醒插入就绪队列

s.value初值为1时，可以用来实现进程的互斥。

p操作和v操作是不可中断的程序段，称为原语。如果将信号量看作共享变量，则pv操作为其临界区，多个进程不能同时执行，一般用硬件方法保证。一个信号量只能置一次初值，以后只能对之进行p操作或v操作。

由此也可以看到，信号量机制必须有公共内存，不能用于分布式操作系统，这是它最大的弱点。

V原语的主要操作是：

⑴sem加1；

⑵若相加结果大于零，则进程继续执行；

⑶若相加结果小于或等于零，则唤醒一阻塞在该信号量上的进程，然后再返回原进程继续执行或转进程调度。

利用信号量和PV操作实现进程互斥的一般模型是：

进程P1 进程P2 …… 进程Pn

……　 ……　 ……

P（S）；　 P（S）；　 P（S）；

临界区；　 临界区；　 临界区；

V（S）；　 V（S）；　 V（S）；

……　 ……　 …… ……

其中信号量S用于互斥，初值为1。

使用PV操作实现进程互斥时应该注意的是：

⑴每个程序中用户实现互斥的P、V操作必须成对出现，先做P操作，进临界区，后做V操作，出临界区。若有多个分支，要认真检查其成对性。

⑵P、V操作应分别紧靠临界区的头尾部，临界区的代码应尽可能短，不能有死循环。

⑶互斥信号量的初值一般为1。

利用信号量和PV操作实现进程同步：

PV操作是典型的同步机制之一。用一个信号量与一个消息联系起来，当信号量的值为0时，表示期望的消息尚未产生；当信号量的值非0时，表示期望的消息已经存在。用PV操作实现进程同步时，调用P操作测试消息是否到达，调用V操作发送消息。

使用PV操作实现进程同步时应该注意的是：

⑴分析进程间的制约关系，确定信号量种类。在保持进程间有正确的同步关系情况下，哪个进程先执行，哪些进程后执行，彼此间通过什么资源（信号量）进行协调，从而明确要设置哪些信号量。

⑵信号量的初值与相应资源的数量有关，也与P、V操作在程序代码中出现的位置有关。

⑶同一信号量的P、V操作要成对出现，但它们分别在不同的进程代码中。

典型理解偏差

三个问题：

一，以V原语的1、2步来做，Sem不就永远大于0，那进程不就一直循环执行成为死循环了？

二，Sem大于0那就表示有临界资源可供使用，为什么不唤醒进程？

三，Sem小于0应该是说没有临界资源可供使用，为什么还要唤醒进程？

析疑：

一，P操作对sem减1的。P、V原语必须成对使用！从而不会造成死循环。

二，Sem大于0的确表示有临界资源可供使用，而且这个时候没有进程被阻塞在这个资源上，也就是说没有进程因为得不到这类资源而阻塞，所以没有被阻塞的进程，自然不需要唤醒。

三，V原语操作的本质在于：一个进程使用完临界资源后，释放临界资源，使Sem加1，以通知其它的进程，这个时候如果Sem<0，表明有进程阻塞在该类资源上，因此要从阻塞队列里唤醒一个进程来“转手”该类资源。比如，有两个某类资源，四个进程A、B、C、D要用该类资源，最开始Sem=2，当A进入，Sem=1，当B进入Sem=0，表明该类资源刚好用完， 当C进入时Sem=-1，表明有一个进程被阻塞了，D进入，Sem=-2。当A用完该类资源时，进行V操作，Sem=-1，释放该类资源，而这时Sem<0，表明有进程阻塞在该类资源上，于是唤醒一个。

为了进一步加深理解，再引入二个问题：

四，如果是互斥信号量的话，应该设置信号量Sem=1，但是当有5个进程都访问的话，最后在该信号量的链表里会有4个在等待，也是说S=-4，那么第一个进程执行了V操作使S加1，释放了资源，下一个应该能够执行，但唤醒的这个进程在执行P操作时因S〈0，也还是执行不了，这是怎么回事呢？

五，Sem的绝对值表示等待的进程数，同时又表示临界资源，这到底是怎么回事？

析疑：

四，当一个进程阻塞了的时候，它已经执行过了P操作，并卡在临界区那个地方。当唤醒它时就立即进入它自己的临界区，并不需要执行P操作了，当执行完了临界区的程序后，就执行V操作。

五，当信号量Sem小于0时，其绝对值表示系统中因请求该类资源而被阻塞的进程数目.S大于0时表示可用的临界资源数。注意在不同情况下所表达的含义不一样。当等于0时，表示刚好用完。