一、訊號燈概述

訊號燈與其他程序間通訊方式不大相同，它主要提供對程序間共享資源訪問控制機制。相當於記憶體中的標誌，程序可以根據它判定是否能夠訪問某些共享資源，同時，程序也可以修改該標誌。除了用於訪問控制外，還可用於程序同步。訊號燈有以下兩種型別：

• 二值訊號燈：最簡單的訊號燈形式，訊號燈的值只能取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 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、檔名到鍵值

它返回與路徑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只有三個，使用時需要包括幾個標頭檔案：

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結構如下：

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所能指定的操作。

呼叫返回：呼叫失敗返回-1，成功返回與cmd相關：

五、訊號燈的限制

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、利用訊號燈實現共享資源的申請和釋放。並在程式中給出了詳細註釋。