针对上一篇文章的关于信号灯的操作问题，以及结构体sumbuf，节选自[url]http://www.ibm.com/developerworks/cn/linux/l-ipc/part4/index.html[/url]Linux环境进程间通信（四）郑彦兴 ([email]mlinux@163.com[/email])国防科大计算机学院的一篇文章可以说明
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

1、 打开或创建信号灯
与消息队列的创建及打开基本相同，不再详述。
2、 信号灯值操作
linux可以增加或减小信号灯的值，相应于对共享资源的释放和占有。具体参见后面的semop系统调用。
3、 获得或设置信号灯属性：
系统中的每一个信号灯集都对应一个struct sem_array结构，该结构记录了信号灯集的各种信息，存在于系统空间。为了设置、获得该信号灯集的各种信息及属性，在用户空间有一个重要的联合结构与之对应，即union semun。

信号灯的操作_Linux
联合semun数据结构各成员意义参见附录2
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；