＂互斥(mutext)和旗語(semaphore)之間有什么不同？＂這樣的問題簡短而有力，但要回答卻相當困難．即使有經(jīng)驗的實時操作系統(tǒng)(RTOS)用戶在區(qū)別如何正確使用mutex和semaphore時也存在著困難．
但這一點很不幸而且很危險，因為無任這兩種原生RTOS中的哪一種被錯誤使用，都會導致嵌入式系統(tǒng)出現(xiàn)意想不到的錯誤，特別是這些系統(tǒng)為有關生命安全的產(chǎn)品時.
有關mutex和semaphore的荒誕說法是它們是相似的，甚至是可以互換的．正確的事實是盡管mutex和semaphore在它們的執(zhí)行上有相似之處，但是我們還是應該在使用它們時加以區(qū)別對待．
最普遍（但也是不正確）的答案是：mutex和semphore非常相似，它們只有一個區(qū)別，那就是semaphores的計數(shù)可以超過1. 差不多所有的工程師都能正確的理解：mutex是一個二進制標志，可以通過它來確保執(zhí)行流在代碼關鍵區(qū)(critical section of code)互相排斥,從而對共享資源加一保護．但當他們被要求進一步回答如何使用＂計算方法semaphore"的方式時，大部分工程師的回答就如同教科書書一般的刻板---semaphore用于保護多重同類資源．
通過類比辦法，我們很容易解釋為什么"多重資源＂場景是有缺陷的.如果你認為一個mutex是由操作系統(tǒng)擁有的關鍵值的話，我們可以很容易地將個別的mutex比喻是城市咖啡店中一間浴室的鑰匙．如果你想使用浴室，卻找不到鑰匙，你就必須在一個隊列中等候．同樣地，mutex則協(xié)串行化多項任務，以取得全域資源的共享，并且為等待隊列中的任務分配一個靜候其循序漸進的位置．
但這種簡單的資源保護協(xié)議并不使用于兩間相同浴室的情況．如果把一個semaphore概括為一個mutex，使其能保護兩個或更多相同的資源，那么在我們的比喻中，它就象是放著兩把相同鑰匙的藍子，你可以用任何一把打開任何一扇浴室的門．
因此，semaphore本身并不能解決多個相同資源的問題．咖啡店中的客人可能只知道有一把鑰匙，但并不知道哪間浴室可用．如果你試圖以此方式使用semaphore，你將會發(fā)現(xiàn)需要更多的狀態(tài)信息---它們通常是由不同的mutex所保護的共享資源．
正確使用semaphore是為了使信號從一項任務傳至另一項任務．mutex意味著取得與釋放，使用受保護共享資源的每一次任務都是以這樣的順序進行．相比之下，使用semaphore的任務通常不是發(fā)送信號，就是進入等待狀態(tài)，不可能同時發(fā)生．
例如，任務1可能包含程序代碼，當按下＂電源＂(power)按鈕時，即可提出(如發(fā)送信號或增量)一個特別的semaphore; 任務2則依據(jù)相同的semaphore而用于喚醒顯示器. 在這種情況下，其中一項任務是信號的生產(chǎn)者，另一項任務是信號的消費者．
用一個例子來做總結(jié)，首先展示如何使用mutex：
/* Task 1 */
mutexWait(mutex_mens_room);
// Safely use shared resource
mutexRelease(mutex_mens_room);
/* Task 2 */
mutexWait(mutex_mens_room);
// Safely use shared resource
mutexRelease(mutex_mens_room);
相應地，你總是采用下列方法使用semaphore:
/* Task 1 - Producer */
semPost(sem_power_btn); // Send the signal
/* Task 2 - Consumer */
semPend(sem_power_btn); // Wait for signal
重要的是，semaphores可以被interrupt service routine(ISR)中斷服務程序用來向task發(fā)送信號．發(fā)送一個semaphore是一個非阻塞的RTOS行為，并且ISR安全．因為這種技術排除了在task級別的為了是中斷不使能而引起的錯誤的可能性，從ISR中發(fā)出信號是一種使嵌入式軟件更加可靠的設計方式.
http://www.embedded.com/columns/guest/210605040?printable=true
http://www.eettaiwan.com/ART_8800557420_676964_NT_a22f6436.HTM