信號燈
一、信號燈概述
信號燈與其他進程間通信方式不大相同，它主要提供對進程間共享資源訪問控制機制。相當于內存中的標志，進程可以根據它判定是否能夠訪問某些共享資源，同時，進程也可以修改該標志。除了用于訪問控制外，還可用于進程同步。信號燈有以下兩種類型：
* 二值信號燈：最簡單的信號燈形式，信號燈的值只能取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