Linux環境程序間通訊（四） 訊號燈(轉)
轉自http://www.ibm.com/developerworks/cn/linux/l-ipc/part4/， 作者：鄭彥興
訊號燈與其他程序間通訊方式不大相同，它主要提供對程序間共享資源訪問控制機制。相當於記憶體中的標誌，程序可以根據它判定是否能夠訪問某些共享資源，同時，程序也可以修改該標誌。除了用於訪問控制外，還可用於程序同步。訊號燈有以下兩種型別：
- 二值訊號燈：最簡單的訊號燈形式，訊號燈的值只能取0或1，類似於互斥鎖。
注：二值訊號燈能夠實現互斥鎖的功能，但兩者的關注內容不同。訊號燈強調共享資源，只要共享資源可用，其他程序同樣可以修改訊號燈的值；互斥鎖更強調程序，佔用資源的程序使用完資源後，必須由程序本身來解鎖。 - 計算訊號燈：訊號燈的值可以取任意非負值（當然受核心本身的約束）。
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
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>
引數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