Mutex是一把鑰匙，一個人拿了就可進入一個房間，出來的時候把鑰匙交給隊列的第一個。一般的用法是用於串行化對critical section代碼的訪問，保證這段代碼不會被並行的運行。
Semaphore是一件可以容納N人的房間，如果人不滿就可以進去，如果人滿了，就要等待有人出來。對於N=1的情況，稱爲binary semaphore。一般的用法是，用於限制對於某一資源的同時訪問。
Binary semaphore與Mutex的差異：
在有的系統中Binary semaphore與Mutex是沒有差異的。在有的系統上，主要的差異是mutex一定要由獲得鎖的進程來釋放。而semaphore可以由其它進程釋放（這時的semaphore實際就是個原子的變量，大家可以加或減），因此semaphore可以用於進程間同步。Semaphore的同步功能是所有系統都支持的，而Mutex能否由其他進程釋放則未定，因此建議mutex只用於保護critical section。而semaphore則用於保護某變量，或者同步。
- class semaphore
- {
- public:
- Semaphore(int count, int max_count);
- ~Semaphore();
- void Unsignal();//等待操作P,count--，如果count==0則等待
- void Signal();//釋放操作V，count++
- }
- classmutex
- {
- public:
- waitMutex();//阻塞線程，直到其它線程釋放互斥鎖
- releaseMutex();//釋放線程
- }
另一個概念是spin lock，這是一個內核態概念。spin lock與semaphore的主要區別是spin lock是busy waiting，而semaphore是sleep。對於可以sleep的進程來說，busy waiting當然沒有意義。對於單CPU的系統，busy waiting當然更沒意義（沒有CPU可以釋放鎖）。因此，只有多CPU的內核態非進程空間，纔會用到spin lock。Linux kernel的spin lock在非SMP的情況下，只是關irq，沒有別的操作，用於確保該段程序的運行不會被打斷。其實也就是類似mutex的作用，串行化對 critical section的訪問。但是mutex不能保護中斷的打斷，也不能在中斷處理程序中被調用。而spin lock也一般沒有必要用於可以sleep的進程空間。
---------------------------------------------------------------------------------------------
內核同步措施
爲了避免併發，防止競爭。內核提供了一組同步方法來提供對共享數據的保護。我們的重點不是介紹這些方法的詳細用法，而是強調爲什麼使用這些方法和它們之間的差別。
Linux 使用的同步機制可以說從2.0到2.6以來不斷髮展完善。從最初的原子操作，到後來的信號量，從大內核鎖到今天的自旋鎖。這些同步機制的發展伴隨 Linux從單處理器到對稱多處理器的過度；伴隨着從非搶佔內核到搶佔內核的過度。鎖機制越來越有效，也越來越複雜。
目前來說內核中原子操作多用來做計數使用，其它情況最常用的是兩種鎖以及它們的變種:一個是自旋鎖，另一個是信號量。我們下面就來着重介紹一下這兩種鎖機制。
自旋鎖
自旋鎖是專爲防止多處理器併發而引入的一種鎖，它在內核中大量應用於中斷處理等部分(對於單處理器來說，防止中斷處理中的併發可簡單採用關閉中斷的方式，不需要自旋鎖)。
自旋鎖最多隻能被一個內核任務持有，如果一個內核任務試圖請求一個已被爭用(已經被持有)的自旋鎖，那麼這個任務就會一直進行忙循環——旋轉——等待鎖重新可用。要是鎖未被爭用，請求它的內核任務便能立刻得到它並且繼續進行。自旋鎖可以在任何時刻防止多於一個的內核任務同時進入臨界區，因此這種鎖可有效地避免多處理器上併發運行的內核任務競爭共享資源。
事實上，自旋鎖的初衷就是：在短期間內進行輕量級的鎖定。一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用的期間進行自旋(特別浪費處理器時間)，所以自旋鎖不應該被持有時間過長。如果需要長時間鎖定的話, 最好使用信號量。
自旋鎖的基本形式如下：
spin_lock(&mr_lock);
//臨界區
spin_unlock(&mr_lock);
因爲自旋鎖在同一時刻只能被最多一個內核任務持有，所以一個時刻只有一個線程允許存在於臨界區中。這點很好地滿足了對稱多處理機器需要的鎖定服務。在單處理器上，自旋鎖僅僅當作一個設置內核搶佔的開關。如果內核搶佔也不存在，那麼自旋鎖會在編譯時被完全剔除出內核。
簡單的說，自旋鎖在內核中主要用來防止多處理器中併發訪問臨界區，防止內核搶佔造成的競爭。另外自旋鎖不允許任務睡眠(持有自旋鎖的任務睡眠會造成自死鎖——因爲睡眠有可能造成持有鎖的內核任務被重新調度，而再次申請自己已持有的鎖)，它能夠在中斷上下文中使用。
死鎖：假設有一個或多個內核任務和一個或多個資源，每個內核都在等待其中的一個資源，但所有的資源都已經被佔用了。這便會發生所有內核任務都在相互等待，但它們永遠不會釋放已經佔有的資源，於是任何內核任務都無法獲得所需要的資源，無法繼續運行，這便意味着死鎖發生了。自死瑣是說自己佔有了某個資源，然後自己又申請自己已佔有的資源，顯然不可能再獲得該資源，因此就自縛手腳了。
信號量
Linux中的信號量是一種睡眠鎖。如果有一個任務試圖獲得一個已被持有的信號量時，信號量會將其推入等待隊列，然後讓其睡眠。這時處理器獲得自由去執行其它代碼。當持有信號量的進程將信號量釋放後，在等待隊列中的一個任務將被喚醒，從而便可以獲得這個信號量。
信號量的睡眠特性，使得信號量適用於鎖會被長時間持有的情況；只能在進程上下文中使用，因爲中斷上下文中是不能被調度的；另外當代碼持有信號量時，不可以再持有自旋鎖。
信號量基本使用形式爲：
static DECLARE_MUTEX(mr_sem);//聲明互斥信號量
if(down_interruptible(&mr_sem))
//可被中斷的睡眠，當信號來到，睡眠的任務被喚醒
//臨界區
up(&mr_sem);
信號量和自旋鎖區別
雖然聽起來兩者之間的使用條件複雜，其實在實際使用中信號量和自旋鎖並不易混淆。注意以下原則:
如果代碼需要睡眠——這往往是發生在和用戶空間同步時——使用信號量是唯一的選擇。由於不受睡眠的限制，使用信號量通常來說更加簡單一些。如果需要在自旋鎖和信號量中作選擇，應該取決於鎖被持有的時間長短。理想情況是所有的鎖都應該儘可能短的被持有，但是如果鎖的持有時間較長的話，使用信號量是更好的選擇。另外，信號量不同於自旋鎖，它不會關閉內核搶佔，所以持有信號量的代碼可以被搶佔。這意味者信號量不會對影響調度反應時間帶來負面影響。
自旋鎖對信號量
需求 建議的加鎖方法
低開銷加鎖 優先使用自旋鎖
短期鎖定 優先使用自旋鎖
長期加鎖 優先使用信號量
中斷上下文中加鎖 使用自旋鎖
持有鎖是需要睡眠、調度 使用信號量
---------------------------------------------------------------------------------------------
臨界區（Critical Section）
保證在某一時刻只有一個線程能訪問數據的簡便辦法。在任意時刻只允許一個線程對共享資源進行訪問。如果有多個線程試圖同時訪問臨界區，那麼在有一個線程進入後其他所有試圖訪問此臨界區的線程將被掛起，並一直持續到進入臨界區的線程離開。臨界區在被釋放後，其他線程可以繼續搶佔，並以此達到用原子方式操作共享資源的目的。
在使用臨界區時，一般不允許其運行時間過長，只要進入臨界區的線程還沒有離開，其他所有試圖進入此臨界區的線程都會被掛起而進入到等待狀態，並會在一定程度上影響。程序的運行性能。尤其需要注意的是不要將等待用戶輸入或是其他一些外界干預的操作包含到臨界區。如果進入了臨界區卻一直沒有釋放，同樣也會引起其他線程的長時間等待。雖然臨界區同步速度很快，但卻只能用來同步本進程內的線程，而不可用來同步多個進程中的線程。
互斥量（Mutex）
互斥（Mutex）是一種用途非常廣泛的內核對象。能夠保證多個線程對同一共享資源的互斥訪問。同臨界區有些類似，只有擁有互斥對象的線程才具有訪問資源的權限，由於互斥對象只有一個，因此就決定了任何情況下此共享資源都不會同時被多個線程所訪問。當前佔據資源的線程在任務處理完後應將擁有的互斥對象交出，以便其他線程在獲得後得以訪問資源。與其他幾種內核對象不同，互斥對象在操作系統中擁有特殊代碼，並由操作系統來管理，操作系統甚至還允許其進行一些其他內核對象所不能進行的非常規操作。互斥量跟臨界區很相似，只有擁有互斥對象的線程才具有訪問資源的權限，由於互斥對象只有一個，因此就決定了任何情況下此共享資源都不會同時被多個線程所訪問。當前佔據資源的線程在任務處理完後應將擁有的互斥對象交出，以便其他線程在獲得後得以訪問資源。互斥量比臨界區複雜。因爲使用互斥不僅僅能夠在同一應用程序不同線程中實現資源的安全共享，而且可以在不同應用程序的線程之間實現對資源的安全共享。
信號量（Semaphores）
信號量對象對線程的同步方式與前面幾種方法不同，信號允許多個線程同時使用共享資源，這與操作系統中的PV操作相同。它指出了同時訪問共享資源的線程最大數目。它允許多個線程在同一時刻訪問同一資源，但是需要限制在同一時刻訪問此資源的最大線程數目。在用CreateSemaphore（）創建信號量時即要同時指出允許的最大資源計數和當前可用資源計數。一般是將當前可用資源計數設置爲最大資源計數，每增加一個線程對共享資源的訪問，當前可用資源計數就會減1，只要當前可用資源計數是大於0的，就可以發出信號量信號。但是當前可用計數減小到0時則說明當前佔用資源的線程數已經達到了所允許的最大數目，不能在允許其他線程的進入，此時的信號量信號將無法發出。線程在處理完共享資源後，應在離開的同時通過ReleaseSemaphore（）函數將當前可用資源計數加1。在任何時候當前可用資源計數決不可能大於最大資源計數。信號量是通過計數來對線程訪問資源進行控制的，而實際上信號量確實也被稱作Dijkstra計數器。
PV操作及信號量的概念都是由荷蘭科學家E.W.Dijkstra提出的。信號量S是一個整數，S大於等於零時代表可供併發進程使用的資源實體數，但S小於零時則表示正在等待使用共享資源的進程數。
P操作申請資源：
（1）S減1；
（2）若S減1後仍大於等於零，則進程繼續執行；
（3）若S減1後小於零，則該進程被阻塞後進入與該信號相對應的隊列中，然後轉入進程調度。
V操作釋放資源：
（1）S加1；
（2）若相加結果大於零，則進程繼續執行；
（3）若相加結果小於等於零，則從該信號的等待隊列中喚醒一個等待進程，然後再返回原進程繼續執行或轉入進程調度。
信號量的使用特點使其更適用於對Socket（套接字）程序中線程的同步。例如，網絡上的HTTP服務器要對同一時間內訪問同一頁面的用戶數加以限制，這時可以爲沒一個用戶對服務器的頁面請求設置一個線程，而頁面則是待保護的共享資源，通過使用信號量對線程的同步作用可以確保在任一時刻無論有多少用戶對某一頁面進行訪問，只有不大於設定的最大用戶數目的線程能夠進行訪問，而其他的訪問企圖則被掛起，只有在有用戶退出對此頁面的訪問後纔有可能進入。
總結：
1．互斥量與臨界區的作用非常相似，但互斥量是可以命名的，也就是說它可以跨越進程使用。所以創建互斥量需要的資源更多，所以如果只爲了在進程內部是用的話使用臨界區會帶來速度上的優勢並能夠減少資源佔用量。因爲互斥量是跨進程的互斥量一旦被創建，就可以通過名字打開它。
2．互斥量（Mutex），信號燈（Semaphore）都可以被跨越進程使用來進行同步數據操作，而其他的對象與數據同步操作無關，但對於進程和線程來講，如果進程和線程在運行狀態則爲無信號狀態，在退出後爲有信號狀態。
3．通過互斥量可以指定資源被獨佔的方式使用，但如果有下面一種情況通過互斥量就無法處理，比如現在一位用戶購買了一份三個併發訪問許可的數據庫系統，可以根據用戶購買的訪問許可數量來決定有多少個線程/進程能同時進行數據庫操作，這時候如果利用互斥量就沒有辦法完成這個要求，信號燈對象可以說是一種資源計數器
