一. linux為什么需要臨界段，信號量，互斥鎖，自旋鎖，原子操作？
1.1. linux內核后期版本是支持多核CPU以及搶占式調度。這里就存在一個並發，競爭狀態（簡稱竟態）。
1.2. 競態條件 發生在兩個或更多線程操縱一個共享數據項時，在多處理器（MP）計算機中也存在並發，其中每個處理器中共享相同數據的線程同時執行
1.3. 臨界段，信號量，互斥鎖，自旋鎖，原子操作可以從不同情形解決上述問題
二. 臨界區（Critical Section）
2.1. 保證在某一時刻只有一個線程能訪問數據的簡便辦法。在任意時刻只允許一個線程對共享資源進行訪問。如果有多個線程試圖同時訪問臨界區，那么在有一個線 程進入后其他所有試圖訪問此臨界區的線程將被掛起，並一直持續到進入臨界區的線程離開。臨界區在被釋放后，其他線程可以繼續搶占，並以此達到用原子方式操 作共享資源的目的。
2.2. 臨界區包含兩個操作原語：
EnterCriticalSection（） 進入臨界區
LeaveCriticalSection（） 離開臨界區
EnterCriticalSection（）語句執行后代碼將進入臨界區以后無論發生什么，必須確保與之匹配的
LeaveCriticalSection（）都能夠被執行到。否則臨界區保護的共享資源將永遠不會被釋放。雖然臨界區同步速度很快，但卻只能用來同步本 進程內的線程，而不可用來同步多個進程中的線程。
2.3. MFC提供了很多功能完備的類，我用MFC實現了臨界區。MFC為臨界區提供有一個CCriticalSection類，使用該類進行線程同步處理是 非常簡單的。只需在線程函數中用CCriticalSection類成員函數Lock（）和UnLock（）標定出被保護代碼片段即可。Lock（）后代 碼用到的資源自動被視為臨界區內的資源被保護。UnLock后別的線程才能訪問這些資源。
三. 互斥量（Mutex）
3.1. 互斥量跟臨界區很相似，只有擁有互斥對象的線程才具有訪問資源的權限，由於互斥對象只有一個，因此就決定了任何情況下此共享資源都不會同時被多個線程 所訪問。當前占據資源的線程在任務處理完后應將擁有的互斥對象交出，以便其他線程在獲得后得以訪問資源。互斥量比臨界區復雜。因為使用互斥不僅僅能夠在同 一應用程序不同線程中實現資源的安全共享，而且可以在不同應用程序的線程之間實現對資源的安全共享。
3.2. 互斥量包含的幾個操作原語：
CreateMutex（） 創建一個互斥量
OpenMutex（） 打開一個互斥量
ReleaseMutex（） 釋放互斥量
WaitForMultipleObjects（） 等待互斥量對象
四. 信號量（Semaphores）
4.1. 信號量對象對線程的同步方式與前面幾種方法不同，信號允許多個線程同時使用共享資源，這與操作系統中的PV操作相同。它指出了同時訪問共享資源的線程 最大數目。它允許多個線程在同一時刻訪問同一資源，但是需要限制在同一時刻訪問此資源的最大線程數目。在用CreateSemaphore（）創建信號量 時即要同時指出允許的最大資源計數和當前可用資源計數。一般是將當前可用資源計數設置為最大資源計數，每增加一個線程對共享資源的訪問，當前可用資源計數 就會減1，只要當前可用資源計數是大於0的，就可以發出信號量信號。但是當前可用計數減小到0時則說明當前占用資源的線程數已經達到了所允許的最大數目， 不能在允許其他線程的進入，此時的信號量信號將無法發出。線程在處理完共享資源后，應在離開的同時通過ReleaseSemaphore（）函數將當前可 用資源計數加1。在任何時候當前可用資源計數決不可能大於最大資源計數。 PV操作及信號量的概念都是由荷蘭科學家E.W.Dijkstra提出的。信號量S是一個整數，S大於等於零時代表可供並發進程使用的資源實體數，但S小於零時則表示正在等待使用共享資源的進程數
P操作 申請資源：
（1）S減1；
（2）若S減1后仍大於等於零，則進程繼續執行；
（3）若S減1后小於零，則該進程被阻塞后進入與該信號相對應的隊列中，然后轉入進程調度。
V操作 釋放資源：
（1）S加1；
（2）若相加結果大於零，則進程繼續執行；
（3）若相加結果小於等於零，則從該信號的等待隊列中喚醒一個等待進程，然后再返回原進程繼續執行或轉入進程調度。
4.2. 信號量包含的幾個操作原語：
CreateSemaphore（） 創建一個信號量
OpenSemaphore（） 打開一個信號量
ReleaseSemaphore（） 釋放信號量
WaitForSingleObject（） 等待信號量
五. 自旋鎖（spin_lock）
5.1. 是為實現保護共享資源而提出一種鎖機制。其實，自旋鎖與互斥鎖比較類似，它們都是為了解決對某項資源的互斥使用。無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有一個保持者，也就說，在任何時刻最多只能有一個執行單元獲得鎖。但是兩者在調度機制上略有不同。對於互斥鎖，如果資源已經被占用，資源申請者只能進入睡眠狀態。但是自旋鎖不會引起調用者睡眠，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那里看是否該自旋鎖的保持者已經釋放了鎖，"自旋"一詞就是因此而得名。
5.2. 自旋鎖和信號量的使用要點
(1)自旋鎖不能遞歸
(2)自旋鎖可以用在中斷上下文（信號量不可以，因為可能睡眠），但是在中斷上下文中獲取自旋鎖之前要先禁用本地中斷,中斷是不參與系統調度的
(3)自旋鎖的核心要求是：擁有自旋鎖的代碼必須不能睡眠，要一直持有CPU直到釋放自旋鎖
(4)信號量和讀寫信號量適合於保持時間較長的情況，它們會導致調用者睡眠，因此只能在進程上下文使用，而自旋鎖適合於保持時間非常短的情況，它可以在任何上下文使用。如果被保護的共享資源只在進程上下文訪問，使用信號量保護該共享資源非常合適，如果對共享資源的訪問時間非常短，自旋鎖也可以。但是如果被保護的共享資源需要在中斷上下文訪問（包括底半部即中斷處理句柄和頂半部即軟中斷），就必須使用自旋鎖。自旋鎖保持期間是搶占失效的，而信號量和讀寫信號量保持期間是可以被搶占的。自旋鎖只有在內核可搶占或SMP（多處理器）的情況下才真正需要，在單CPU且不可搶占的內核下，自旋鎖的所有操作都是空操作。
六. 原子操作
6.1. Linux原子概念
6.1.1. 所謂原子操作，就是“不可中斷的一個或一系列操作”。
6.1.2. 原子操作，就是不能被更高等級中斷搶奪優先的操作。你既然提這個問題，我就說深一點。由於操作系統大部分時間處於開中斷狀態，所以，一個程序在執行的時候可能被優先級更高的線程中斷。而有些操作是不能被中斷的，不然會出現無法還原的后果，這時候，這些操作就需要原子操作。就是不能被中斷的操作。
6.1.3. 硬件級的原子操作：在單處理器系統（UniProcessor）中，能夠在單條指令中完成的操作都可以認為是“原子操作”，因為中斷只發生在指令邊緣。在多處理器結構中（Symmetric Multi-Processor）就不同了，由於系統中有多個處理器獨立運行，即使能在單條指令中完成的操作也有可能受到干擾。在X86平台生，CPU提供了在指令執行期間對總線加鎖的手段。CPU上有一根引線#HLOCK pin連到北橋，如果匯編語言的程序中在一條指令前面加上前綴"LOCK"，經過匯編以后的機器代碼就使CPU在執行這條指令的時候把#HLOCK pin的電位拉低，持續到這條指令結束時放開，從而把總線鎖住，這樣同一總線上別的CPU就暫時不能通過總線訪問內存了，保證了這條指令在多處理器環境中的原子性。對於其他平台的CPU，實現各不相同，有的是通過關中斷來實現原子操作（sparc），有的通過CMPXCHG系列的指令來實現原子操作（IA64）。本文主要探討X86平台下原子操作的實現。
6.2. Linux內核兩組原子操作接口：
6.2.1. 原子整數操作
原子操作通常針對int或bit類型的數據，但是Linux並不能直接對int進行原子操作，而只能通過atomic_t的數據結構來進行。定義於#include<asm/atomic.h>
6.2.2. 內核中提供的一些主要位原子操作函數
同時內核還提供了一組與上述操作對應的非原子位操作函數，名字前多兩下划線。由於不保證原子性，因此速度可能執行更快。
七. 總結：
7.1． 互斥量與臨界區的作用非常相似，但互斥量是可以命名的，也就是說它可以跨越進程使用。所以創建互斥量需要的資源更多，所以如果只為了在進程內部是用的話使 用臨界區會帶來速度上的優勢並能夠減少資源占用量。因為互斥量是跨進程的互斥量一旦被創建，就可以通過名字打開它。
7.2． 通過互斥量可以指定資源被獨占的方式使用，但如果有下面一種情況通過互斥量就無法處理，比如現在一位用戶購買了一份三個並發訪問許可的數據庫系統，可以根 據用戶購買的訪問許可數量來決定有多少個線程/進程能同時進行數據庫操作，這時候如果利用互斥量就沒有辦法完成這個要求，信號燈對象可以說是一種資源計數 器。
7.3. 互斥鎖與信號量的區別：
7.3.1、信號量一般以同步的方式對共享資源進行控制，而互斥鎖通過互斥的方式對共享資源對其進行控制；
7.3.2、信號量可以對進程的共享資源進行控制，而互斥鎖不行；
7.3.3、信號量的值為非負整數，而互斥鎖的值只能為0或1；
7.3.4、互斥量的加鎖和解鎖必須由同一線程分別對應使用，信號量可以由一個線程釋放，另一個線程得到；mutex和二值信號量的區別在於mutex必須是同一個進程來釋放
7.4. 自旋鎖與互斥鎖的區別：
7.4.1、因為自旋鎖不會引起調用者睡眠，所以效率比較高
7.4.2、自旋鎖比較適用於鎖使用者保持鎖時間比較短的情況。
7.4.3、自旋鎖容易造成死鎖，所以需要安全使用它；
索引文獻：https://www.cnblogs.com/linhaostudy/p/6670693.html
索引文獻：https://www.cnblogs.com/wuhezhi/p/4853678.html?ptvd