⑴ linux常用信號量
linux的常用信號量
BUS與SEGV
二者都是錯誤信號，BUS表示匯流排錯誤，SEGV表示段錯誤，程序崩潰的時候99%都是這兩個錯誤導
致的。進程可以捕獲和封鎖這兩類錯誤。內核對二者的默認處理是memory mp
WINCH
窗口改變信號（WINdown CHanged）。例如虛擬終端的行數發生變化時將發送WINCH信號，絕大多數
文本編輯器都能捕獲WINCH信號自動進行重新配置。內核的默認處理是忽略該信號，並且不進行內存
轉儲。
進程可以捕獲或者封鎖該信號
KILL
殺死/刪除進程，編號為9
STOP
掛起/暫停正在執行的進程，直到收到CONT為止
KILL STOP都不能夠被捕獲、封鎖或者忽略，默認處理都不會產生內存轉儲。
CONT
取消掛起，繼續執行進程
TSTP
是STOP信號的「軟」版本，即在用戶輸入Ctrl+Z時由終端驅動程序發送的信號。捕獲到該信號的進程通常
清除它們的狀態，如何給自己發送一個STOP信號。TSTP的默認處理不會導致內存轉儲。
INT
中斷信號，編號為2
當用戶輸入Ctrl+C時由終端驅動程序發送INT信號
INT信號是終止當前操作的請求，簡單程序捕獲到INT信號時應該退出，擁有命令行或者輸入模式的那些
程序應該停止他們正在做的事情，清除狀態，並等待用戶再次輸入。
TERM
軟體終止信號，編號為15
TERM是請求徹底終止某項操作的信號，它期望進程清楚自己的狀態並退出
QUIT
退出信號，編號為3
與TERM類似，不同之處在於QUIT信號的默認處理是內存轉儲，而TERM信號的默認處理沒有內存轉儲。
HUP
掛起信號，編號為1，有兩種解釋：
守護進程理解HUP為重新設置的請求，如果守護進程能夠不用重新啟動就能夠重新讀取它自己的配置文
件並調整自己以適應變化的話，那麼HUP信號通常可以用來觸發這種行為
HUP
信號有時有終端驅動程序生成，試圖用來清除（也就是終止）跟某個特定終端相連接的那些進程。例如
當一個終端會話結束時，或者當一個Modem的連接不經意的斷開時，就可能出現這種情況。
如果需要某些進程在會話結束之後繼續運行，那麼在C Shell中設法讓這些進程變成後台程序，
ksh或者bash中可以用nohup來模擬這種行為。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
進程的四種狀態
runnable（可運行狀態）
只要有CPU時間，進程就可以執行。一旦進程執行了不能立即完成的系統調用，Linux會把進程轉入
睡眠狀態
sleeping（睡眠狀態）
進程在等待某些事件發生（如終端輸入、網路連接）
zombie（僵化狀態）
進程已經執行完畢並試圖消亡，但是狀態沒有收集完
stopped（停止狀態）
進程被掛起，不允許執行。進程收到STOP或者TSTP信號即進入停止狀態，可以用CONT信號來重新啟動
⑵ linux 信號燈和信號量的區別
信號量是與signal相關的內容，是進程間通信的一種方式，一個進程可以向另一個進程發送一個信號作為通知，除了signal系統調用外，相關內容還有：
SEE ALSO
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), bsd_signal(3), raise(3), sigin-
terrupt(3), sigqueue(3), sigsetops(3), sigvec(3), sysv_signal(3), signal(7)
信號量也是進程通信的一種方式，一般用於並發取得資源對應鎖或者其他互斥操作，除了semget系統調用外，相關內容還有：
SEE ALSO
semctl(2), semop(2), ftok(3), capabilities(7), sem_overview(7), svipc(7)
⑶ Linux信號 機制和Linux信號量機制的區別
首先，一句話總結它們之間的區別：
字面上相似，但是本質上存在巨大的差別！請看詳細解答...
Linux信號（signal) 機制
signal，又簡稱為信號（軟中斷信號）用來通知進程發生了非同步事件。
原理：
一個進程收到一個信號與處理器收到一個中斷請求可以說是一樣的。信號是進程間通信機制中唯一的非同步通信機制，一個進程不必通過任何操作來等待信號的到達，事實上，進程也不知道信號到底什麼時候到達。進程之間可以互相通過系統調用kill發送軟中斷信號。內核也可以因為內部事件而給進程發送信號，通知進程發生了某個事件。信號機制除了基本通知功能外，還可以傳遞附加信息。
分類：
從兩個不同的分類角度對信號進行：
可靠性方面：可靠信號與不可靠信號；
與時間的關繫上：實時信號與非實時信號。
部分定義轉自：http://www.cnblogs.com/hoys/archive/2012/08/19/2646377.html
Linux信號量（semaphore）機制
Linux內核的信號量用來操作系統進程間同步訪問共享資源。
原理：信號量在創建時需要設置一個初始值，表示同時可以有幾個任務可以訪問該信號量保護的共享資源，初始值為1就變成互斥鎖（Mutex），即同時只能有一個任務可以訪問信號量保護的共享資源。
一個任務要想訪問共享資源，首先必須得到信號量，獲取信號量的操作將把信號量的值減1，若當前信號量的值為負數，表明無法獲得信號量，該任務必須掛起在該信號量的等待隊列等待該信號量可用；若當前信號量的值為非負數，表示可以獲得信號量，因而可以立刻訪問被該信號量保護的共享資源。
當任務訪問完被信號量保護的共享資源後，必須釋放信號量，釋放信號量通過把信號量的值加1實現，如果信號量的值為非正數，表明有任務等待當前信號量，因此它也喚醒所有等待該信號量的任務。
常用的信號量的API：
DECLARE_MUTEX(name)
該宏聲明一個信號量name並初始化它的值為0，即聲明一個互斥鎖。
DECLARE_MUTEX_LOCKED(name)
該宏聲明一個互斥鎖name，但把它的初始值設置為0，即鎖在創建時就處在已鎖狀態。因此對於這種鎖，一般是先釋放後獲得。
void sema_init (struct semaphore *sem, int val);
該函用於數初始化設置信號量的初值，它設置信號量sem的值為val。
void init_MUTEX (struct semaphore *sem);
該函數用於初始化一個互斥鎖，即它把信號量sem的值設置為1。
void init_MUTEX_LOCKED (struct semaphore *sem);
該函數也用於初始化一個互斥鎖，但它把信號量sem的值設置為0，即一開始就處在已鎖狀態。
void down(struct semaphore * sem);
該函數用於獲得信號量sem，它會導致睡眠，因此不能在中斷上下文（包括IRQ上下文和softirq上下文）使用該函數。該函數將把sem的值減1，如果信號量sem的值非負，就直接返回，否則調用者將被掛起，直到別的任務釋放該信號量才能繼續運行。
int down_interruptible(struct semaphore * sem);
該函數功能與down類似，不同之處為，down不會被信號（signal）打斷，但down_interruptible能被信號打斷，因此該函數有返回值來區分是正常返回還是被信號中斷，如果返回0，表示獲得信號量正常返回，如果被信號打斷，返回-EINTR。
int down_trylock(struct semaphore * sem);
該函數試著獲得信號量sem，如果能夠立刻獲得，它就獲得該信號量並返回0，否則，表示不能獲得信號量sem，返回值為非0值。因此，它不會導致調用者睡眠，可以在中斷上下文使用。
void up(struct semaphore * sem);
該函數釋放信號量sem，即把sem的值加1，如果sem的值為非正數，表明有任務等待該信號量，因此喚醒這些等待者。
實例：
信號量在絕大部分情況下作為互斥鎖使用，下面以console驅動系統為例說明信號量的使用。
在內核源碼樹的kernel/printk.c中，使用宏DECLARE_MUTEX聲明了一個互斥鎖console_sem，它用於保護console驅動列表console_drivers以及同步對整個console驅動系統的訪問。
⑷ Linux信號量
信號量是包含一個非負整數型的變數，並且帶有兩個原子操作wait和signal。Wait還可以被稱為down、P或lock，signal還可以被稱為up、V、unlock或post。在UNIX的API中（POSIX標准）用的是wait和post。
對於wait操作，如果信號量的非負整形變數S大於0，wait就將其減1，如果S等於0，wait就將調用線程阻塞；對於post操作，如果有線程在信號量上阻塞（此時S等於0），post就會解除對某個等待線程的阻塞，使其從wait中返回，如果沒有線程阻塞在信號量上，post就將S加1.
由此可見，S可以被理解為一種資源的數量，信號量即是通過控制這種資源的分配來實現互斥和同步的。如果把S設為1，那麼信號量即可使多線程並發運行。另外，信號量不僅允許使用者申請和釋放資源，而且還允許使用者創造資源，這就賦予了信號量實現同步的功能。可見信號量的功能要比互斥量豐富許多。
POSIX信號量是一個sem_t類型的變數，但POSIX有兩種信號量的實現機制： 無名信號量 和 命名信號量 。無名信號量只可以在共享內存的情況下，比如實現進程中各個線程之間的互斥和同步，因此無名信號量也被稱作基於內存的信號量；命名信號量通常用於不共享內存的情況下，比如進程間通信。
同時，在創建信號量時，根據信號量取值的不同，POSIX信號量還可以分為：
下面是POSIX信號量函數介面：
信號量的函數都以sem_開頭，線程中使用的基本信號函數有4個，他們都聲明在頭文件semaphore.h中，該頭文件定義了用於信號量操作的sem_t類型：
【sem_init函數】：
該函數用於創建信號量，原型如下：
該函數初始化由sem指向的信號對象，設置它的共享選項，並給它一個初始的整數值。pshared控制信號量的類型，如果其值為0，就表示信號量是當前進程的局部信號量，否則信號量就可以在多個進程間共享，value為sem的初始值。
該函數調用成功返回0，失敗返回-1。
【sem_destroy函數】：
該函數用於對用完的信號量進行清理，其原型如下：
成功返回0，失敗返回-1。
【sem_wait函數】：
該函數用於以原子操作的方式將信號量的值減1。原子操作就是，如果兩個線程企圖同時給一個信號量加1或減1，它們之間不會互相干擾。其原型如下：
sem指向的對象是sem_init調用初始化的信號量。調用成功返回0，失敗返回-1。
sem_trywait()則是sem_wait()的非阻塞版本，當條件不滿足時（信號量為0時），該函數直接返回EAGAIN錯誤而不會阻塞等待。
sem_timedwait()功能與sem_wait()類似，只是在指定的abs_timeout時間內等待，超過時間則直接返回ETIMEDOUT錯誤。
【sem_post函數】：
該函數用於以原子操作的方式將信號量的值加1，其原型如下：
與sem_wait一樣，sem指向的對象是由sem_init調用初始化的信號量。調用成功時返回0，失敗返回-1。
【sem_getvalue函數】：
該函數返回當前信號量的值，通過restrict輸出參數返回。如果當前信號量已經上鎖（即同步對象不可用），那麼返回值為0，或為負數，其絕對值就是等待該信號量解鎖的線程數。
【實例1】：
【實例2】：
之所以稱為命名信號量，是因為它有一個名字、一個用戶ID、一個組ID和許可權。這些是提供給不共享內存的那些進程使用命名信號量的介面。命名信號量的名字是一個遵守路徑名構造規則的字元串。
【sem_open函數】：
該函數用於創建或打開一個命名信號量，其原型如下：
參數name是一個標識信號量的字元串。參數oflag用來確定是創建信號量還是連接已有的信號量。
oflag的參數可以為0，O_CREAT或O_EXCL：如果為0，表示打開一個已存在的信號量；如果為O_CREAT，表示如果信號量不存在就創建一個信號量，如果存在則打開被返回，此時mode和value都需要指定；如果為O_CREAT|O_EXCL，表示如果信號量存在則返回錯誤。
mode參數用於創建信號量時指定信號量的許可權位，和open函數一樣，包括：S_IRUSR、S_IWUSR、S_IRGRP、S_IWGRP、S_IROTH、S_IWOTH。
value表示創建信號量時，信號量的初始值。
【sem_close函數】：
該函數用於關閉命名信號量：
單個程序可以用sem_close函數關閉命名信號量，但是這樣做並不能將信號量從系統中刪除，因為命名信號量在單個程序執行之外是具有持久性的。當進程調用_exit、exit、exec或從main返回時，進程打開的命名信號量同樣會被關閉。
【sem_unlink函數】：
sem_unlink函數用於在所有進程關閉了命名信號量之後，將信號量從系統中刪除：
【信號量操作函數】：
與無名信號量一樣，操作信號量的函數如下:
命名信號量是隨內核持續的。當命名信號量創建後，即使當前沒有進程打開某個信號量，它的值依然保持，直到內核重新自舉或調用sem_unlink()刪除該信號量。
無名信號量的持續性要根據信號量在內存中的位置確定：
很多時候信號量、互斥量和條件變數都可以在某種應用中使用，那這三者的差異有哪些呢？下面列出了這三者之間的差異：
⑸ Linux進程通信實驗（共享內存通信，接上篇）
這一篇記錄一下共享內存實驗，需要linux的共享內存機制有一定的了解，同時也需要了解POSIX信號量來實現進程間的同步。可以參考以下兩篇博客: https://blog.csdn.net/sicofield/article/details/10897091
https://blog.csdn.net/ljianhui/article/details/10253345
實驗要求：編寫sender和receiver程序，sender創建一個共享內存並等待用戶輸入，然後把輸入通過共享內存發送給receiver並等待，receiver收到後把消息顯示在屏幕上並用同樣方式向sender發送一個over，然後兩個程序結束運行。
這個實驗的難點主要在於共享內存的創建和撤銷（涉及到的步驟比較多，需要理解各步驟的功能），以及實現兩個進程間的相互等待（使用信號量來實現，這里使用了有名信號量）
實驗心得：學習理解了linux的共享內存機制以及POSIX信號量機制。
兩個實驗雖然加強了對linux一些機制的理解，但是感覺對linux的學習還不夠，需要繼續學習。