信號燈
信號燈與其他進程間通信方式不大相同，它主要提供對進程間共享資源訪問控制機制。相當于內存中的標志，進程可以根據它判定是否能夠訪問某些共享資源（臨界區，類似于互斥鎖），同時，進程也可以修改該標志。除了用于訪問控制外，還可用于進程同步。
1. 信號燈概述
信號燈與其他進程間通信方式不大相同，它主要提供對進程間共享資源訪問控制機制。相當于內存中的標志，進程可以根據它判定是否能夠訪問某些共享資源（臨界區，類似于互斥鎖），同時，進程也可以修改該標志。除了用于訪問控制外，還可用于進程同步。信號燈有以下兩種類型：
- 二值信號燈：最簡單的信號燈形式，信號燈的值只能取0或1，類似于互斥鎖。
注：二值信號燈能夠實現互斥鎖的功能，但兩者的關注內容不同。信號燈強調共享資源，只要共享資源可用，其他進程同樣可以修改信號燈的值；互斥鎖更強調進程，占用資源的進程使用完資源后，必須由進程本身來解鎖。 - 計算信號燈：信號燈的值可以取任意非負值（當然受內核本身的約束）。
2. linux信號燈
linux對信號燈的支持狀況與消息隊列一樣，在red had 8.0發行版本中支持的是系統V的信號燈。因此，本文將主要介紹系統V信號燈及其相應API。在沒有聲明的情況下，以下討論中指的都是系統V信號燈。
注意，通常所說的系統V信號燈指的是計數信號燈集。
3. 信號燈與內核
1、系統V信號燈是隨內核持續的，只有在內核重起或者顯示刪除一個信號燈集時，該信號燈集才會真正被刪除。因此系統中記錄信號燈的數據結構（struct ipc_ids sem_ids）位于內核中，系統中的所有信號燈都可以在結構sem_ids中找到訪問入口。
2、下圖說明了內核與信號燈是怎樣建立起聯系的：
其中：structipc_ids sem_ids是內核中記錄信號燈的全局數據結構；描述一個具體的信號燈及其相關信息。
其中，struct sem結構如下：
struct sem
{
int semval; // current value
int sempid; // pid of last operation
}
從上圖可以看出，全局數據結構struct ipc_ids sem_ids可以訪問到struct ipc_id ipcid的一個成員：struct kern_ipc_perm；而每個struct kern_ipc_perm能夠與具體的信號燈集對應起來是因為在該結構中，有一個key_t類型成員key，而key則唯一確定一個信號燈集struct sem_array；同時，結構struct sem_array的最后一個成員sem_nsems確定了該信號燈在信號燈集中的順序，這樣內核就能夠記錄每個信號燈的信息了。
kern_ipc_perm結構如下：
//內核中全局數據結構sem_ids能夠訪問到該結構；
struct kern_ipc_perm
{
key_t key; //該鍵值則唯一對應一個信號燈集
uid_t uid;
gid_t gid;
uid_t cuid;
gid_t cgid;
mode_t mode;
unsigned long seq;
}
/*系統中的每個信號燈集對應一個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 */
};
需要C/C++ Linux服務器架構師學習資料私信“資料”（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等），免費分享
4. 操作信號燈
對信號燈的操作無非有下面三種類型：
1、打開或創建信號燈 與消息隊列的創建及打開基本相同，不再詳述。
2、信號燈值操作 linux可以增加或減小信號燈的值，相應于對共享資源的釋放和占有。具體參見后面的semop系統調用。
3、獲得或設置信號燈屬性： 系統中的每一個信號燈集都對應一個struct sem_array結構，該結構記錄了信號燈集的各種信息，存在于系統空間。為了設置、獲得該信號燈集的各種信息及屬性，在用戶空間有一個重要的聯合結構與之對應，即union semun。
聯合semun數據結構：
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;
};
The semid_ds data structure is defined in <sys/sem.h> as follows:
struct semid_ds {
struct ipc_perm sem_perm; /* Ownership and permissions */
time_t sem_otime; /* Last semop time */
time_t sem_ctime; /* Last change time */
unsigned short sem_nsems; /* No. of semaphores in set */
};
The ipc_perm structure is defined in <sys/ipc.h> as follows (the highlighted fields are settable using IPC_SET):
struct ipc_perm {
key_t key; /* Key supplied to semget() */
uid_t uid; /* Effective UID of owner */
gid_t gid; /* Effective GID of owner */
uid_t cuid; /* Effective UID of creator */
gid_t cgid; /* Effective GID of creator */
unsigned short mode; /* Permissions */
unsigned short seq; /* Sequence number */
};
seminfo, defined in <sys/sem.h> if the _GNU_SOURCE feature test macro is defined:
struct seminfo {
int semmap; /* #(number?) of entries in semaphore map;
unused */
int semmni; /* Max. # of semaphore sets */
int semmns; /* Max. # of semaphores in all
semaphore sets */
int semmnu; /* System-wide max. # of undo
structures; unused */
int semmsl; /* Max. # of semaphores in a set */
int semopm; /* Max. # of operations for semop() */
int semume; /* Max. # of undo entries per
process; unused */
int semusz; /* size of struct sem_undo */
int semvmx; /* Maximum semaphore value */
int semaem; /* Max. value that can be recorded for
semaphore adjustment (SEM_UNDO) */
};
The semmsl, semmns, semopm, and semmni settings can be changed via /proc/sys/kernel/sem; see proc(5) for details.
信號燈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, intsecond, 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所代表的信號燈已經存在，且semflg指定了IPC_CREAT|IPC_EXCL標志，那么即使參數nsems與原來信號燈的數目不等，返回的也是EEXIST錯誤；如果semflg只指定了IPC_CREAT標志，那么參數nsems必須與原來的值一致，在后面程序實例中還要進一步說明。
Upon creation, the least significant 9 bits of the argument semflg define the permissions (for owner, group and others) for the semaphore set. These bits have the same format, and the same meaning, as the mode argument of open(2) (though the execute permissions are not meaningful for semaphores, and write permissions mean permission to alter semaphore values)
例如：IPC_CREAT | 權限標識
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到相應的信號量集的資源總數（ipc_perm.sem_nsems）之間的整數，0對應第一個信號燈。
sem_flg可取IPC_NOWAIT以及SEM_UNDO兩個標志。如果設置了SEM_UNDO標志，那么在進程結束時，相應的操作將被取消，這是比較重要的一個標志位。如果設置了該標志位，那么在進程沒有釋放共享資源就退出時，內核將代為釋放。如果為一個信號燈設置了該標志，內核都要分配一個sem_undo結構來記錄它，為的是確保以后資源能夠安全釋放。事實上，如果進程退出了，那么它所占用的資源就釋放了，但信號燈值卻沒有改變，此時，信號燈值反映的已經不是資源占有的實際情況，在這種情況下，問題的解決就靠內核來完成。這有點像僵尸進程，進程雖然退出了，資源也都釋放了，但內核進程表中仍然有它的記錄，此時就需要父進程調用waitpid來解決問題了。
sem_op的值大于0，等于0以及小于0確定了對sem_num指定的信號燈進行的三種操作。具體請參考linux相應手冊頁。 （是信號量在一次操作中需要改變的數值（可以是非1的數值）。通常只會用到兩個值：-1----P操作，申請資源，如果已經沒有資源可申請，則阻塞。為阻塞原語；1---V操作，釋放資源，為喚醒原語。）
也許從實際含義上更好理解這些操作：信號燈的當前值記錄相應資源目前可用數目；sem_op>0對應相應進程要釋放sem_op數目的共享資源；sem_op=0可以用于對共享資源是否已用完的測試；sem_op<0相當于進程要申請-sem_op個共享資源。再聯想操作的原子性，更不難理解該系統調用何時正常返回，何時睡眠等待。調用返回：成功返回0，否則返回-1。
若sem_op 是正數，其值就加到semval上，即釋放信號量控制的資源若sem_op 是0，那么調用者希望等到semval變為0，如果semval是0就返回;若sem_op 是負數，那么調用者希望等待到semval變為大于或等于sem_op的絕對值。如果當前semval大于或等于sem_op的絕對值，則立即返回。
這里需要強調的是semop同時操作多個信號燈，在實際應用中，對應多種資源的申請或釋放。semop保證操作的原子性，這一點尤為重要。尤其對于多種資源的申請來說，要么一次性獲得所有資源，要么放棄申請，要么在不占有任何資源情況下繼續等待，這樣，一方面避免了資源的浪費；另一方面，避免了進程之間由于申請共享資源造成死鎖。
3) int semctl(int semid，int semnum，int cmd，union semun arg) 該系統調用實現對信號燈的各種控制操作，參數semid指定信號燈集，參數cmd指定具體的操作類型；參數semnum指定對哪個信號燈操作，只對幾個特殊的cmd操作有意義；arg用于設置或返回信號燈信息。該系統調用詳細信息請參見其手冊頁，這里只給出參數cmd所能指定的操作。
IPC_RMID Immediately remove the semaphore set, awakening all processes blocked in semop()
calls on the set (with an error return and errno set to EIDRM). The effective user ID
of the calling process must match the creator or owner of the semaphore set, or the
caller must be privileged. The argument semnum is ignored.
調用返回：調用失敗返回-1，成功返回與cmd相關：
5. 信號燈的限制
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調用應該注意的。
6. 競爭問題
第一個創建信號燈的進程同時也初始化信號燈，這樣，系統調用semget包含了兩個步驟：創建信號燈；初始化信號燈。由此可能導致一種競爭狀態：第一個創建信號燈的進程在初始化信號燈時，第二個進程又調用semget，并且發現信號燈已經存在，此時，第二個進程必須具有判斷是否有進程正在對信號燈進行初始化的能力。在參考文獻[1]中，給出了繞過這種競爭狀態的方法：當semget創建一個新的信號燈時，信號燈結構semid_ds的sem_otime成員初始化后的值為0。因此，第二個進程在成功調用semget后，可再次以IPC_STAT命令調用semctl，等待sem_otime變為非0值，此時可判斷該信號燈已經初始化完畢。下圖描述了競爭狀態產生及解決方法：
實際上，這種解決方法也是基于這樣一個假定：第一個創建信號燈的進程必須調用semop，這樣sem_otime才能變為非零值。另外，因為第一個進程可能不調用semop，或者semop操作需要很長時間，第二個進程可能無限期等待下去，或者等待很長時間。
7. 信號燈應用實例
本實例有兩個目的：1、獲取各種信號燈信息；2、利用信號燈實現共享資源的申請和釋放。并在程序中給出了詳細注釋。
#include <stdio.h>
#include <sys/sem.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
#define SEM_PATH "/unix/my_sem"
#define max_tries 10
#ifndef IPC_INFO
#define IPC_INFO 3 /* see ipcs */
#endif
int gi_semid;
const int gi_semcnt = 1;
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;
};
int main()
{
int i_flag_create, i_flag_get, i_key, i, i_init_ok, i_tmperrno;
struct semid_ds semid_ds_var;
struct seminfo seminfo_var;
union semun semun_arg;
struct sembuf sembuf_ask, sembuf_free;
i_flag_create = IPC_CREAT | IPC_EXCL | 00666;
i_flag_get = IPC_CREAT | 00666;
i_key = ftok( SEM_PATH, 'a' );
//error handling for ftok here;
i_init_ok = 0;
gi_semid = semget( i_key, gi_semcnt, i_flag_create );
//create a semaphore set that only includes one semaphore.
if( gi_semid < 0 )
{
i_tmperrno = errno;
perror( "semget" );
if( i_tmperrno == EEXIST )
//errno is undefined after a successful library call( including perror call)
//so it is saved in i_tmperrno.
{
gi_semid = semget( i_key, gi_semcnt, i_flag_get );
// i_flag_get 只包含了IPC_CREAT標志, 參數nsems(這里為1)
// 必須與原來的信號燈數目一致
semun_arg.buf = &semid_ds_var;
for ( i = 0; i < max_tries; i++ )
{
printf( "semctl IPC_STAT, to solve compete: %d n", i );
if ( semctl( gi_semid, 0, IPC_STAT, semun_arg ) == -1 )
{
perror( "semctl error" );
i = max_tries;
}
else
{
if( semun_arg.buf->sem_otime != 0 )
// the create process already initialized the semaphore
{
i = max_tries;
i_init_ok = 1;
}
else
sleep(1);
}
} // for(i=0; i<max_tries; i++)
if( !i_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.
{
printf( "semctl SETVALn" );
semun_arg.val = 1;
if ( semctl( gi_semid, 0, SETVAL, semun_arg ) == -1 )
perror( "semctl SETVAL error" );
} // if(!i_init_ok)
} // if(i_tmperrno==EEXIST)
else
{
perror("semget error, process exit");
exit( 1 );
}
}
else //gi_semid>=0; do some initializing
{
printf( "create semaphore success, initialize itn" );
semun_arg.val = 1;
if ( semctl( gi_semid, 0, SETVAL, semun_arg ) == -1 )
perror( "semctl SETVAL error" );
}
//get some information about the semaphore and the limit of semaphore in redhat8.0
semun_arg.buf=&semid_ds_var;
if( semctl( gi_semid, 0, IPC_STAT, semun_arg ) == -1 )
perror("semctl IPC STAT");
printf( "owner's uid is %dn", semun_arg.buf->sem_perm.uid );
printf( "owner's gid is %dn", semun_arg.buf->sem_perm.gid );
printf( "creater's uid is %dn", semun_arg.buf->sem_perm.cuid );
printf( "creater's gid is %dn", semun_arg.buf->sem_perm.cgid );
semun_arg.__buf = &seminfo_var;
if( semctl( gi_semid, 0, IPC_INFO, semun_arg ) == -1 )
perror( "semctl IPC_INFO" );
printf( "the number of entries in semaphore map is %d n", semun_arg.__buf->semmap );
printf( "max number of semaphore identifiers is %d n", semun_arg.__buf->semmni );
printf( "mas number of semaphores in system is %d n", semun_arg.__buf->semmns );
printf( "the number of undo structures system wide is %d n", semun_arg.__buf->semmnu );
printf( "max number of semaphores per gi_semid is %d n", semun_arg.__buf->semmsl );
printf( "max number of ops per semop call is %d n", semun_arg.__buf->semopm );
printf( "max number of undo entries per process is %d n", semun_arg.__buf->semume );
printf( "the sizeof of struct sem_undo is %d n", semun_arg.__buf->semusz );
printf( "the maximum semaphore value is %d n", semun_arg.__buf->semvmx );
// print sem_otime
semun_arg.buf = &semid_ds_var;
if ( semctl( gi_semid, 0, IPC_STAT, semun_arg ) == -1 )
{
perror( "semctl error" );
i = max_tries;
}
else
{
printf( "before semop, semun_arg.buf->sem_otime: %lun", semun_arg.buf->sem_otime );
}
//now ask for available resource:
printf( "now ask the resourcen" );
sembuf_ask.sem_num = 0;
sembuf_ask.sem_op = -1;
sembuf_ask.sem_flg = SEM_UNDO;
if( semop( gi_semid, &sembuf_ask, 1 ) == -1 ) //ask for resource
perror("semop error");
printf( "ask the resource successn" );
// print sem_otime
semun_arg.buf = &semid_ds_var;
if ( semctl( gi_semid, 0, IPC_STAT, semun_arg ) == -1 )
{
perror( "semctl error" );
i = max_tries;
}
else
{
printf( "after semop, semun_arg.buf->sem_otime: %lun", semun_arg.buf->sem_otime );
}
sleep(5);
//do some handling on the sharing resource here, just sleep on it 3 seconds
printf( "now free the resourcen" );
//now free resource
sembuf_free.sem_num = 0;
sembuf_free.sem_op = 1;
sembuf_free.sem_flg = SEM_UNDO;
if ( semop( gi_semid, &sembuf_free, 1 ) == -1 ) //free the resource.
if( errno == EIDRM )
printf( "the semaphore set has been removedn" );
//you can comment out the codes below to compile a different version:
if( semctl( gi_semid, 0, IPC_RMID ) == -1 )
perror( "semctl IPC_RMID" );
else
printf("remove sem okn");
return 0;
}
注：讀者可以嘗試一下注釋掉初始化步驟，進程在運行時會出現何種情況（進程在申請資源時會睡眠），同時可以像程序結尾給出的注釋那樣，把該程序編譯成兩個不同版本。下面是本程序的運行結果（操作系統gentoo）：
create semaphore success, initialize it
owner's uid is 1007
owner's gid is 1007
creater's uid is 1007
creater's gid is 1007
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 gi_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
before semop, semun_arg.buf->sem_otime: 0
now ask the resource
ask the resource success
after semop, semun_arg.buf->sem_otime: 1398501342
now free the resource
remove sem ok
Summary：信號燈與其它進程間通信方式有所不同，它主要用于進程間同步。通常所說的系統V信號燈實際上是一個信號燈的集合，可用于多種共享資源的進程間同步。每個信號燈都有一個值，可以用來表示當前該信號燈代表的共享資源可用（available）數量，如果一個進程要申請共享資源，那么就從信號燈值中減去要申請的數目，如果當前沒有足夠的可用資源，進程可以睡眠等待，也可以立即返回。當進程要申請多種共享資源時，linux可以保證操作的原子性，即要么申請到所有的共享資源，要么放棄所有資源，這樣能夠保證多個進程不會造成互鎖。Linux對信號燈有各種各樣的限制，程序中給出了輸出結果。另外，如果讀者想對信號燈作進一步的理解，建議閱讀sem.h源代碼，該文件不長，但給出了信號燈相關的重要數據結構。
