spinlocklinux
Ⅰ 關於linux自旋鎖
既然是對一個變數進行保護，當然是一個自旋鎖了，還沒見過一個變數能當兩個用的。
我覺得你對這段代碼的理解有問題，用 spin_lock 和 spin_unlock 的目的是保證程序在對 xxx_lock 進行操作的時候，不會有其它進程改變這個值，是為了保證數據的准確性。
你可以設想一下，如果沒有自旋鎖，代碼運行起來會有什麼問題。假設 A,B兩個進程同時訪問 open ， 沒有使用自旋鎖，此時 xxx_lock=0, A 進程在判斷 if (xxx_count) 時，會認為設備沒有被使用，那麼它會繼續後面的 xxx_count++ 操作，但假如這時 CPU 切換進程， A 進程還沒有來得及把 xxx_count 變成 1 的時候， B 進程開始運行，那麼 B 進程此時也會認為設備沒有被使用，它也會進行後繼操作，這樣就會出現兩個進程同時訪問設備的錯誤。
open 和 release 當然可以同時訪問，只不過在運行 spin_lock 的時候，後訪問的進程會被阻塞而已。假設有 A 進程訪問 open ，B 進程訪問 release ，你可以把這種情況理解為 A ， B 進程同時訪問 open 函數，這樣或許能更好的理解這段代碼。因為 open 和 release 在使用自旋鎖的時候，方法是一樣的。
spin_lock 和 CPU 系統無關，不管是單 CPU 還是多 CPU ，運行結果都是一樣的。
這個邏輯關系比較難解釋，不知道你看懂我的意思沒。
Ⅱ 如何使用spinlock要哪個頭文件
在kernel2.4.20下面：
include <linux/spinlock.h>
spinlock_t mysiglock = SPIN_LOCK_UNLOCKED;
unsigned int flags;
然後：
spin_lock_irqsave(&mysiglock,flags);
spin_unlock_irqrestore(&mysiglock,flags);
可以編譯，但連接的時候kernel.o時說：
undefined reference to 'local_irq_save'
Ⅲ linux原子操作和自旋鎖的區別
現代操作系統支持多任務的並發，並發在提高計算資源利用率的同時也帶來了資源競爭的問題。例如C語言語句「count++;」在未經編譯器優化時生成的匯編代碼為。
當操作系統內存在多個進程同時執行這段代碼時，就可能帶來並發問題。
假設count變數初始值為0。進程1執行完「mov eax, [count]」後，寄存器eax內保存了count的值0。此時，進程2被調度執行，搶佔了進程1的CPU的控制權。進程2執行「count++;」的匯編代碼，將累加後的count值1寫回到內存。然後，進程1再次被調度執行，CPU控制權回到進程1。進程1接著執行，計算count的累加值仍為1，寫回到內存。雖然進程1和進程2執行了兩次「count++;」操作，但是count實際的內存值為1，而不是2！
單處理器原子操作
解決這個問題的方法是，將「count++;」語句翻譯為單指令操作。
Intel x86指令集支持內存操作數的inc操作，這樣「count++;」操作可以在一條指令內完成。因為進程的上下文切換是在總是在一條指令執行完成後，所以不會出現上述的並發問題。對於單處理器來說，一條處理器指令就是一個原子操作。
多處理器原子操作
但是在多處理器的環境下，例如SMP架構，這個結論不再成立。我們知道「inc [count]」指令的執行過程分為三步：
1）從內存將count的數據讀取到cpu。
2）累加讀取的值。
3）將修改的值寫回count內存。
這又回到前面並發問題類似的情況，只不過此時並發的主題不再是進程，而是處理器。
Intel x86指令集提供了指令前綴lock用於鎖定前端串列匯流排（FSB），保證了指令執行時不會受到其他處理器的干擾。
使用lock指令前綴後，處理器間對count內存的並發訪問（讀/寫）被禁止，從而保證了指令的原子性。
x86原子操作實現
Linux的源碼中x86體系結構原子操作的定義文件為。
linux2.6/include/asm-i386/atomic.h
文件內定義了原子類型atomic_t，其僅有一個欄位counter，用於保存32位的數據。
typedef struct { volatile int counter; } atomic_t;
其中原子操作函數atomic_inc完成自加原子操作。
/**
* atomic_inc - increment atomic variable
* @v: pointer of type atomic_t
*
* Atomically increments @v by 1.
*/
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));
}
其中LOCK宏的定義為。
#ifdef CONFIG_SMP
#define LOCK "lock ; "
#else
#define LOCK ""
#endif
可見，在對稱多處理器架構的情況下，LOCK被解釋為指令前綴lock。而對於單處理器架構，LOCK不包含任何內容。
arm原子操作實現
在arm的指令集中，不存在指令前綴lock，那如何完成原子操作呢？
Linux的源碼中arm體系結構原子操作的定義文件為。
linux2.6/include/asm-arm/atomic.h
其中自加原子操作由函數atomic_add_return實現。
static inline int atomic_add_return(int i, atomic_t *v)
{
unsigned long tmp;
int result;
__asm__ __volatile__("@ atomic_add_return\n"
"1: ldrex %0, [%2]\n"
" add %0, %0, %3\n"
" strex %1, %0, [%2]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp)
: "r" (&v->counter), "Ir" (i)
: "cc");
return result;
}
上述嵌入式匯編的實際形式為。
1:
ldrex [result], [v->counter]
add [result], [result], [i]
strex [temp], [result], [v->counter]
teq [temp], #0
bne 1b
ldrex指令將v->counter的值傳送到result，並設置全局標記「Exclusive」。
add指令完成「result+i」的操作，並將加法結果保存到result。
strex指令首先檢測全局標記「Exclusive」是否存在，如果存在，則將result的值寫回counter->v，並將temp置為0，清除「Exclusive」標記，否則直接將temp置為1結束。
teq指令測試temp值是否為0。
bne指令temp不等於0時跳轉到標號1，其中字元b表示向後跳轉。
整體看來，上述匯編代碼一直嘗試完成「v->counter+=i」的操作，直到temp為0時結束。
使用ldrex和strex指令對是否可以保證add指令的原子性呢？假設兩個進程並發執行「ldrex+add+strex」操作，當進程1執行ldrex後設定了全局標記「Exclusive」。此時切換到進程2，執行ldrex前全局標記「Exclusive」已經設定，ldrex執行後重復設定了該標記。然後執行add和strex指令，完成累加操作。再次切換回進程1，接著執行add指令，當執行strex指令時，由於「Exclusive」標記被進程2清除，因此不執行傳送操作，將temp設置為1。後繼teq指令測定temp不等於0，則跳轉到起始位置重新執行，最終完成累加操作！可見ldrex和strex指令對可以保證進程間的同步。多處理器的情況與此相同，因為arm的原子操作只關心「Exclusive」標記，而不在乎前端串列匯流排是否加鎖。
在ARMv6之前，swp指令就是通過鎖定匯流排的方式完成原子的數據交換，但是影響系統性能。ARMv6之後，一般使用ldrex和strex指令對代替swp指令的功能。
自旋鎖中的原子操作
Linux的源碼中x86體系結構自旋鎖的定義文件為。
linux2.6/include/asm-i386/spinlock.h
其中__raw_spin_lock完成自旋鎖的加鎖功能
#define __raw_spin_lock_string \
"\n1:\t" \
"lock ; decb %0\n\t" \
"jns 3f\n" \
"2:\t" \
"rep;nop\n\t" \
"cmpb $0,%0\n\t" \
"jle 2b\n\t" \
"jmp 1b\n" \
"3:\n\t"
static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
__asm__ __volatile__(
__raw_spin_lock_string
:"=m" (lock->slock) : : "memory");
}
上述代碼的實際匯編形式為。
1：
lock decb [lock->slock]
jns 3
2:
rep nop
cmpb $0, [lock->slock]
jle 2
jmp 1
3:
其中lock->slock欄位初始值為1，執行原子操作decb後值為0。符號位為0，執行jns指令跳轉到3，完成自旋鎖的加鎖。
當再次申請自旋鎖時，執行原子操作decb後lock->slock值為-1。符號位為1，不執行jns指令。進入標簽2，執行一組nop指令後比較lock->slock是否小於等於0，如果小於等於0回到標簽2進行循環（自旋）。否則跳轉到標簽1重新申請自旋鎖，直到申請成功。
自旋鎖釋放時會將lock->slock設置為1，這樣保證了其他進程可以獲得自旋鎖。
信號量中的原子操作
Linux的源碼中x86體系結構自旋鎖的定義文件為。
linux2.6/include/asm-i386/semaphore.h
信號量的申請操作由函數down實現。
/*
* This is ugly, but we want the default case to fall through.
* "__down_failed" is a special asm handler that calls the C
* routine that actually waits. See arch/i386/kernel/semaphore.c
*/
static inline void down(struct semaphore * sem)
{
might_sleep();
__asm__ __volatile__(
"# atomic down operation\n\t"
LOCK "decl %0\n\t" /* --sem->count */
"js 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __down_failed\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=m" (sem->count)
:
:"memory","ax");
}
實際的匯編代碼形式為。
lock decl [sem->count]
js 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __down_failed
jmp 1
信號量的sem->count一般初始化為一個正整數，申請信號量時執行原子操作decl，將sem->count減1。如果該值減為負數（符號位為1）則跳轉到另一個段內的標簽2，否則申請信號量成功。
標簽2被編譯到另一個段內，進入標簽2後，執行lea指令取出sem->count的地址，放到eax寄存器作為參數，然後調用函數__down_failed表示信號量申請失敗，進程加入等待隊列。最後跳回標簽1結束信號量申請。
信號量的釋放操作由函數up實現。
/*
* Note! This is subtle. We jump to wake people up only if
* the semaphore was negative (== somebody was waiting on it).
* The default case (no contention) will result in NO
* jumps for both down() and up().
*/
static inline void up(struct semaphore * sem)
{
__asm__ __volatile__(
"# atomic up operation\n\t"
LOCK "incl %0\n\t" /* ++sem->count */
"jle 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __up_wakeup\n\t"
"jmp 1b\n"
LOCK_SECTION_END
".subsection 0\n"
:"=m" (sem->count)
:
:"memory","ax");
}
實際的匯編代碼形式為。
lock incl sem->count
jle 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __up_wakeup
jmp 1
釋放信號量時執行原子操作incl將sem->count加1，如果該值小於等於0，則說明等待隊列有阻塞的進程需要喚醒，跳轉到標簽2，否則信號量釋放成功。
標簽2被編譯到另一個段內，進入標簽2後，執行lea指令取出sem->count的地址，放到eax寄存器作為參數，然後調用函數__up_wakeup喚醒等待隊列的進程。最後跳回標簽1結束信號量釋放。
Ⅳ linux內核同步問題
Linux內核設計與實現 十、內核同步方法
手把手教Linux驅動5-自旋鎖、信號量、互斥體概述
== 基礎概念： ==
並發 ：多個執行單元同時進行或多個執行單元微觀串列執行，宏觀並行執行
競態 ：並發的執行單元對共享資源（硬體資源和軟體上的全局變數）的訪問而導致的竟態狀態。
臨界資源 ：多個進程訪問的資源
臨界區 ：多個進程訪問的代碼段
== 並發場合： ==
1、單CPU之間進程間的並發 :時間片輪轉，調度進程。 A進程訪問列印機，時間片用完，OS調度B進程訪問列印機。
2、單cpu上進程和中斷之間並發 ：CPU必須停止當前進程的執行中斷;
3、多cpu之間
4、單CPU上中斷之間的並發
== 使用偏向： ==
==信號量用於進程之間的同步，進程在信號量保護的臨界區代碼裡面是可以睡眠的（需要進行進程調度），這是與自旋鎖最大的區別。==
信號量又稱為信號燈，它是用來協調不同進程間的數據對象的，而最主要的應用是共享內存方式的進程間通信。本質上，信號量是一個計數器，它用來記錄對某個資源（如共享內存）的存取狀況。它負責協調各個進程，以保證他們能夠正確、合理的使用公共資源。它和spin lock最大的不同之處就是：無法獲取信號量的進程可以睡眠，因此會導致系統調度。
1、==用於進程與進程之間的同步==
2、==允許多個進程進入臨界區代碼執行，臨界區代碼允許睡眠；==
3、信號量本質是==基於調度器的==，在UP和SMP下沒有區別；進程獲取不到信號量將陷入休眠，並讓出CPU；
4、不支持進程和中斷之間的同步
5、==進程調度也是會消耗系統資源的，如果一個int型共享變數就需要使用信號量，將極大的浪費系統資源==
6、信號量可以用於多個線程，用於資源的計數（有多種狀態）
==信號量加鎖以及解鎖過程：==
sema_init(&sp->dead_sem, 0); / 初始化 /
down(&sema);
臨界區代碼
up(&sema);
==信號量定義：==
==信號量初始化：==
==dowm函數實現：==
==up函數實現：==
信號量一般可以用來標記可用資源的個數。
舉2個生活中的例子：
==dowm函數實現原理解析：==
（1）down
判斷sem->count是否 > 0，大於0則說明系統資源夠用，分配一個給該進程，否則進入__down(sem);
（2）__down
調用__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);其中TASK_UNINTERRUPTIBLE=2代表進入睡眠，且不可以打斷；MAX_SCHEDULE_TIMEOUT休眠最長LONG_MAX時間；
（3）list_add_tail(&waiter.list, &sem->wait_list);
把當前進程加入到sem->wait_list中；
（3）先解鎖後加鎖;
進入__down_common前已經加鎖了，先把解鎖，調用schele_timeout(timeout)，當waiter.up=1後跳出for循環；退出函數之前再加鎖；
Linux內核ARM構架中原子變數的底層實現研究
rk3288 原子操作和原子位操作
原子變數適用於只共享一個int型變數；
1、原子操作是指不被打斷的操作，即它是最小的執行單位。
2、最簡單的原子操作就是一條條的匯編指令(不包括一些偽指令，偽指令會被匯編器解釋成多條匯編指令)
==常見函數：==
==以atomic_inc為例介紹實現過程==
在Linux內核文件archarmincludeasmatomic.h中。 執行atomic_read、atomic_set這些操作都只需要一條匯編指令，所以它們本身就是不可打斷的。 需要特別研究的是atomic_inc、atomic_dec這類讀出、修改、寫回的函數。
所以atomic_add的原型是下面這個宏：
atomic_add等效於：
result（%0） tmp（%1） (v->counter)（%2） (&v->counter)（%3） i（%4）
注意：根據內聯匯編的語法，result、tmp、&v->counter對應的數據都放在了寄存器中操作。如果出現上下文切換，切換機制會做寄存器上下文保護。
（1）ldrex %0, [%3]
意思是將&v->counter指向的數據放入result中，並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %0, %0, %4
result = result + i
（3）strex %1, %0, [%3]
意思是將result保存到&v->counter指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %1, #0
測試strex是否成功（tmp == 0 ？？）
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
Spinlock 是內核中提供的一種比較常見的鎖機制，==自旋鎖是「原地等待」的方式解決資源沖突的==，即，一個線程獲取了一個自旋鎖後，另外一個線程期望獲取該自旋鎖，獲取不到，只能夠原地「打轉」（忙等待）。由於自旋鎖的這個忙等待的特性，註定了它使用場景上的限制 —— 自旋鎖不應該被長時間的持有（消耗 CPU 資源），一般應用在==中斷上下文==。
1、spinlock是一種死等機制
2、信號量可以允許多個執行單元進入，spinlock不行，一次只能允許一個執行單元獲取鎖，並且進入臨界區，其他執行單元都是在門口不斷的死等
3、由於不休眠，因此spinlock可以應用在中斷上下文中；
4、由於spinlock死等的特性，因此臨界區執行代碼盡可能的短；
==spinlock加鎖以及解鎖過程：==
spin_lock(&devices_lock);
臨界區代碼
spin_unlock(&devices_lock);
==spinlock初始化==
==進程和進程之間同步==
==本地軟中斷之間同步==
==本地硬中斷之間同步==
==本地硬中斷之間同步並且保存本地中斷狀態==
==嘗試獲取鎖==
== arch_spinlock_t結構體定義如下： ==
== arch_spin_lock的實現如下： ==
lockval（%0） newval（%1） tmp（%2） &lock->slock（%3） 1 << TICKET_SHIFT（%4）
（1）ldrex %0, [%3]
把lock->slock的值賦值給lockval；並且（分別在Local monitor和Global monitor中）設置獨占標志。
（2）add %1, %0, %4
newval =lockval +（1<<16）; 相當於next+1；
（3）strex %2, %1, [%3]
newval =lockval +（1<<16）; 相當於next+1；
意思是將newval保存到 &lock->slock指向的內存中， 此時 Exclusive monitors會發揮作用，將保存是否成功的標志放入tmp中。
（4） teq %2, #0
測試strex是否成功
（5）bne 1b
如果發現strex失敗，從（1）再次執行。
通過上面的分析，可知關鍵在於strex的操作是否成功的判斷上。而這個就歸功於ARM的Exclusive monitors和ldrex/strex指令的機制。
（6）while (lockval.tickets.next != lockval.tickets.owner)
如何lockval.tickets的next和owner是否相等。相同則跳出while循環，否則在循環內等待判斷；
* （7）wfe()和smp_mb() 最終調用#define barrier() asm volatile ("": : :"memory") *
阻止編譯器重排，保證編譯程序時在優化屏障之前的指令不會在優化屏障之後執行。
== arch_spin_unlock的實現如下： ==
退出鎖時：tickets.owner++
== 出現死鎖的情況： ==
1、擁有自旋鎖的進程A在內核態阻塞了，內核調度B進程，碰巧B進程也要獲得自旋鎖，此時B只能自旋轉。 而此時搶占已經關閉，（單核）不會調度A進程了，B永遠自旋，產生死鎖。
2、進程A擁有自旋鎖，中斷到來，CPU執行中斷函數，中斷處理函數，中斷處理函數需要獲得自旋鎖，訪問共享資源，此時無法獲得鎖，只能自旋，產生死鎖。
== 如何避免死鎖： ==
1、如果中斷處理函數中也要獲得自旋鎖，那麼驅動程序需要在擁有自旋鎖時禁止中斷；
2、自旋鎖必須在可能的最短時間內擁有
3、避免某個獲得鎖的函數調用其他同樣試圖獲取這個鎖的函數，否則代碼就會死鎖；不論是信號量還是自旋鎖，都不允許鎖擁有者第二次獲得這個鎖，如果試圖這么做，系統將掛起；
4、鎖的順序規則（a) 按同樣的順序獲得鎖；b) 如果必須獲得一個局部鎖和一個屬於內核更中心位置的鎖，則應該首先獲取自己的局部鎖 ;c) 如果我們擁有信號量和自旋鎖的組合，則必須首先獲得信號量；在擁有自旋鎖時調用down(可導致休眠)是個嚴重的錯誤的；）
== rw（read/write）spinlock： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內有一個讀線程，這時候信賴的read線程可以任意進入，但是寫線程不能進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內有一個或者多個讀線程，寫線程不可以進入臨界區，但是寫線程也無法阻止後續的讀線程繼續進去，要等到臨界區所有的讀線程都結束了，才可以進入，可見：==rw（read/write）spinlock更加有利於讀線程；==
== seqlock（順序鎖）： ==
加鎖邏輯：
1、假設臨界區內沒有任何的thread，這個時候任何的讀線程和寫線程都可以鍵入
2、假設臨界區內沒有寫線程的情況下，read線程可以任意進入；
3、假設臨界區有一個寫線程，這時候任何的讀、寫線程都不可以進入；
4、假設臨界區內只有read線程的情況下，寫線程可以理解執行，不會等待，可見：==seqlock（順序鎖）更加有利於寫線程；==
讀寫速度 ： CPU > 一級緩存 > 二級緩存 > 內存 ，因此某一個CPU0的lock修改了，其他的CPU的lock就會失效；那麼其他CPU就會依次去L1 L2和主存中讀取lock值，一旦其他CPU去讀取了主存，就存在系統性能降低的風險；
mutex用於互斥操作。
互斥體只能用於一個線程，資源只有兩種狀態（佔用或者空閑）
1、mutex的語義相對於信號量要簡單輕便一些，在鎖爭用激烈的測試場景下，mutex比信號量執行速度更快，可擴展
性更好，
2、另外mutex數據結構的定義比信號量小;、
3、同一時刻只有一個線程可以持有mutex
4、不允許遞歸地加鎖和解鎖
5、當進程持有mutex時，進程不可以退出。
• mutex必須使用官方API來初始化。
• mutex可以睡眠，所以不允許在中斷處理程序或者中斷下半部中使用，例如tasklet、定時器等
==常見操作：==
struct mutex mutex_1;
mutex_init(&mutex_1);
mutex_lock(&mutex_1)
臨界區代碼；
mutex_unlock(&mutex_1)
==常見函數：==
=
Ⅳ 如何實現linux下多線程之間的互斥與同步
Linux設備驅動中必須解決的一個問題是多個進程對共享資源的並發訪問，並發訪問會導致競態，linux提供了多種解決競態問題的方式，這些方式適合不同的應用場景。
Linux內核是多進程、多線程的操作系統，它提供了相當完整的內核同步方法。內核同步方法列表如下：
中斷屏蔽
原子操作
自旋鎖
讀寫自旋鎖
順序鎖
信號量
讀寫信號量
BKL（大內核鎖）
Seq鎖
一、並發與競態：
定義：
並發（concurrency）指的是多個執行單元同時、並行被執行，而並發的執行單元對共享資源（硬體資源和軟體上的全局變數、靜態變數等）的訪問則很容易導致競態（race conditions）。
在linux中，主要的競態發生在如下幾種情況：
1、對稱多處理器（SMP）多個CPU
特點是多個CPU使用共同的系統匯流排，因此可訪問共同的外設和存儲器。
2、單CPU內進程與搶占它的進程
3、中斷（硬中斷、軟中斷、Tasklet、底半部）與進程之間
只要並發的多個執行單元存在對共享資源的訪問，競態就有可能發生。
如果中斷處理程序訪問進程正在訪問的資源，則競態也會會發生。
多個中斷之間本身也可能引起並發而導致競態（中斷被更高優先順序的中斷打斷）。
解決競態問題的途徑是保證對共享資源的互斥訪問，所謂互斥訪問就是指一個執行單元在訪問共享資源的時候，其他的執行單元都被禁止訪問。
訪問共享資源的代碼區域被稱為臨界區，臨界區需要以某種互斥機制加以保護，中斷屏蔽，原子操作，自旋鎖，和信號量都是linux設備驅動中可採用的互斥途徑。
臨界區和競爭條件：
所謂臨界區（critical regions）就是訪問和操作共享數據的代碼段，為了避免在臨界區中並發訪問，編程者必須保證這些代碼原子地執行——也就是說，代碼在執行結束前不可被打斷，就如同整個臨界區是一個不可分割的指令一樣，如果兩個執行線程有可能處於同一個臨界區中，那麼就是程序包含一個bug，如果這種情況發生了，我們就稱之為競爭條件（race conditions），避免並發和防止競爭條件被稱為同步。
死鎖：
死鎖的產生需要一定條件：要有一個或多個執行線程和一個或多個資源，每個線程都在等待其中的一個資源，但所有的資源都已經被佔用了，所有線程都在相互等待，但它們永遠不會釋放已經佔有的資源，於是任何線程都無法繼續，這便意味著死鎖的發生。
二、中斷屏蔽
在單CPU范圍內避免競態的一種簡單方法是在進入臨界區之前屏蔽系統的中斷。
由於linux內核的進程調度等操作都依賴中斷來實現，內核搶占進程之間的並發也就得以避免了。
中斷屏蔽的使用方法：
local_irq_disable()//屏蔽中斷
//臨界區
local_irq_enable()//開中斷
特點：
由於linux系統的非同步IO，進程調度等很多重要操作都依賴於中斷，在屏蔽中斷期間所有的中斷都無法得到處理，因此長時間的屏蔽是很危險的，有可能造成數據丟失甚至系統崩潰，這就要求在屏蔽中斷之後，當前的內核執行路徑應當盡快地執行完臨界區的代碼。
中斷屏蔽只能禁止本CPU內的中斷，因此，並不能解決多CPU引發的競態，所以單獨使用中斷屏蔽並不是一個值得推薦的避免競態的方法，它一般和自旋鎖配合使用。
三、原子操作
定義：原子操作指的是在執行過程中不會被別的代碼路徑所中斷的操作。
（原子原本指的是不可分割的微粒，所以原子操作也就是不能夠被分割的指令）
（它保證指令以「原子」的方式執行而不能被打斷）
原子操作是不可分割的，在執行完畢不會被任何其它任務或事件中斷。在單處理器系統(UniProcessor)中，能夠在單條指令中完成的操作都可以認為是" 原子操作"，因為中斷只能發生於指令之間。這也是某些CPU指令系統中引入了test_and_set、test_and_clear等指令用於臨界資源互斥的原因。但是，在對稱多處理器(Symmetric Multi-Processor)結構中就不同了，由於系統中有多個處理器在獨立地運行，即使能在單條指令中完成的操作也有可能受到干擾。我們以decl (遞減指令)為例，這是一個典型的"讀－改－寫"過程，涉及兩次內存訪問。
通俗理解：
原子操作，顧名思義，就是說像原子一樣不可再細分。一個操作是原子操作，意思就是說這個操作是以原子的方式被執行，要一口氣執行完，執行過程不能夠被OS的其他行為打斷，是一個整體的過程，在其執行過程中，OS的其它行為是插不進來的。
分類：linux內核提供了一系列函數來實現內核中的原子操作，分為整型原子操作和位原子操作，共同點是：在任何情況下操作都是原子的，內核代碼可以安全的調用它們而不被打斷。
原子整數操作：
針對整數的原子操作只能對atomic_t類型的數據進行處理，在這里之所以引入了一個特殊的數據類型，而沒有直接使用C語言的int型，主要是出於兩個原因：
第一、讓原子函數只接受atomic_t類型的操作數，可以確保原子操作只與這種特殊類型數據一起使用，同時，這也確保了該類型的數據不會被傳遞給其它任何非原子函數；
第二、使用atomic_t類型確保編譯器不對相應的值進行訪問優化——這點使得原子操作最終接收到正確的內存地址，而不是一個別名，最後就是在不同體系結構上實現原子操作的時候，使用atomic_t可以屏蔽其間的差異。
原子整數操作最常見的用途就是實現計數器。
另一點需要說明原子操作只能保證操作是原子的，要麼完成，要麼不完成，不會有操作一半的可能，但原子操作並不能保證操作的順序性，即它不能保證兩個操作是按某個順序完成的。如果要保證原子操作的順序性，請使用內存屏障指令。
atomic_t和ATOMIC_INIT(i)定義
typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
在你編寫代碼的時候，能使用原子操作的時候，就盡量不要使用復雜的加鎖機制，對多數體系結構來講，原子操作與更復雜的同步方法相比較，給系統帶來的開銷小，對高速緩存行的影響也小，但是，對於那些有高性能要求的代碼，對多種同步方法進行測試比較，不失為一種明智的作法。
原子位操作：
針對位這一級數據進行操作的函數，是對普通的內存地址進行操作的。它的參數是一個指針和一個位號。
為方便其間，內核還提供了一組與上述操作對應的非原子位函數，非原子位函數與原子位函數的操作完全相同，但是，前者不保證原子性，且其名字前綴多兩個下劃線。例如，與test_bit()對應的非原子形式是_test_bit()，如果你不需要原子性操作（比如，如果你已經用鎖保護了自己的數據），那麼這些非原子的位函數相比原子的位函數可能會執行得更快些。
四、自旋鎖
自旋鎖的引入：
如 果每個臨界區都能像增加變數這樣簡單就好了，可惜現實不是這樣，而是臨界區可以跨越多個函數，例如：先得從一個數據結果中移出數據，對其進行格式轉換和解 析，最後再把它加入到另一個數據結構中，整個執行過程必須是原子的，在數據被更新完畢之前，不能有其他代碼讀取這些數據，顯然，簡單的原子操作是無能為力 的（在單處理器系統(UniProcessor)中，能夠在單條指令中完成的操作都可以認為是" 原子操作"，因為中斷只能發生於指令之間），這就需要使用更為復雜的同步方法——鎖來提供保護。
自旋鎖的介紹：
Linux內核中最常見的鎖是自旋鎖（spin lock），自旋鎖最多隻能被一個可執行線程持有，如果一個執行線程試圖獲得一個被爭用（已經被持有）的自旋鎖，那麼該線程就會一直進行忙循環—旋轉—等待鎖重新可用，要是鎖未被爭用，請求鎖的執行線程便能立刻得到它，繼續執行，在任意時間，自旋鎖都可以防止多於一個的執行線程同時進入理解區，注意同一個鎖可以用在多個位置—例如，對於給定數據的所有訪問都可以得到保護和同步。
一個被爭用的自旋鎖使得請求它的線程在等待鎖重新可用時自旋（特別浪費處理器時間），所以自旋鎖不應該被長時間持有，事實上，這點正是使用自旋鎖的初衷，在短期間內進行輕量級加鎖，還可以採取另外的方式來處理對鎖的爭用：讓請求線程睡眠，直到鎖重新可用時再喚醒它，這樣處理器就不必循環等待，可以去執行其他代碼，這也會帶來一定的開銷——這里有兩次明顯的上下文切換， 被阻塞的線程要換出和換入。因此，持有自旋鎖的時間最好小於完成兩次上下文切換的耗時，當然我們大多數人不會無聊到去測量上下文切換的耗時，所以我們讓持 有自旋鎖的時間應盡可能的短就可以了，信號量可以提供上述第二種機制，它使得在發生爭用時，等待的線程能投入睡眠，而不是旋轉。
自旋鎖可以使用在中斷處理程序中（此處不能使用信號量，因為它們會導致睡眠），在中斷處理程序中使用自旋鎖時，一定要在獲取鎖之前，首先禁止本地中斷（在 當前處理器上的中斷請求），否則，中斷處理程序就會打斷正持有鎖的內核代碼，有可能會試圖去爭用這個已經持有的自旋鎖，這樣以來，中斷處理程序就會自旋， 等待該鎖重新可用，但是鎖的持有者在這個中斷處理程序執行完畢前不可能運行，這正是我們在前一章節中提到的雙重請求死鎖，注意，需要關閉的只是當前處理器上的中斷，如果中斷發生在不同的處理器上，即使中斷處理程序在同一鎖上自旋，也不會妨礙鎖的持有者（在不同處理器上）最終釋放鎖。
自旋鎖的簡單理解：
理解自旋鎖最簡單的方法是把它作為一個變數看待，該變數把一個臨界區或者標記為「我當前正在運行，請稍等一會」或者標記為「我當前不在運行，可以被使用」。如果A執行單元首先進入常式，它將持有自旋鎖，當B執行單元試圖進入同一個常式時，將獲知自旋鎖已被持有，需等到A執行單元釋放後才能進入。
自旋鎖的API函數：
其實介紹的幾種信號量和互斥機制，其底層源碼都是使用自旋鎖,可以理解為自旋鎖的再包裝。所以從這里就可以理解為什麼自旋鎖通常可以提供比信號量更高的性能。
自旋鎖是一個互斥設備，他只能會兩個值：「鎖定」和「解鎖」。它通常實現為某個整數之中的單個位。
「測試並設置」的操作必須以原子方式完成。
任何時候，只要內核代碼擁有自旋鎖，在相關CPU上的搶占就會被禁止。
適用於自旋鎖的核心規則：
（1）任何擁有自旋鎖的代碼都必須使原子的，除服務中斷外（某些情況下也不能放棄CPU,如中斷服務也要獲得自旋鎖。為了避免這種鎖陷阱，需要在擁有自旋鎖時禁止中斷），不能放棄CPU（如休眠，休眠可發生在許多無法預期的地方）。否則CPU將有可能永遠自旋下去（死機）。
（2）擁有自旋鎖的時間越短越好。
需 要強調的是，自旋鎖別設計用於多處理器的同步機制，對於單處理器（對於單處理器並且不可搶占的內核來說，自旋鎖什麼也不作），內核在編譯時不會引入自旋鎖 機制，對於可搶占的內核，它僅僅被用於設置內核的搶占機制是否開啟的一個開關，也就是說加鎖和解鎖實際變成了禁止或開啟內核搶占功能。如果內核不支持搶 占，那麼自旋鎖根本就不會編譯到內核中。
內核中使用spinlock_t類型來表示自旋鎖，它定義在：
typedef struct {
raw_spinlock_t raw_lock;
#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
unsigned int break_lock;
#endif
} spinlock_t;
對於不支持SMP的內核來說，struct raw_spinlock_t什麼也沒有，是一個空結構。對於支持多處理器的內核來說，struct raw_spinlock_t定義為
typedef struct {
unsigned int slock;
} raw_spinlock_t;
slock表示了自旋鎖的狀態，「1」表示自旋鎖處於解鎖狀態（UNLOCK），「0」表示自旋鎖處於上鎖狀態（LOCKED）。
break_lock表示當前是否由進程在等待自旋鎖，顯然，它只有在支持搶占的SMP內核上才起作用。
自旋鎖的實現是一個復雜的過程，說它復雜不是因為需要多少代碼或邏輯來實現它，其實它的實現代碼很少。自旋鎖的實現跟體系結構關系密切，核心代碼基本也是由匯編語言寫成，與體協結構相關的核心代碼都放在相關的目錄下，比如。對於我們驅動程序開發人員來說，我們沒有必要了解這么spinlock的內部細節，如果你對它感興趣，請參考閱讀Linux內核源代碼。對於我們驅動的spinlock介面，我們只需包括頭文件。在我們詳細的介紹spinlock的API之前，我們先來看看自旋鎖的一個基本使用格式：
#include
spinlock_t lock = SPIN_LOCK_UNLOCKED;
spin_lock(&lock);
....
spin_unlock(&lock);
從使用上來說，spinlock的API還很簡單的，一般我們會用的的API如下表，其實它們都是定義在中的宏介面，真正的實現在中
#include
SPIN_LOCK_UNLOCKED
DEFINE_SPINLOCK
spin_lock_init( spinlock_t *)
spin_lock(spinlock_t *)
spin_unlock(spinlock_t *)
spin_lock_irq(spinlock_t *)
spin_unlock_irq(spinlock_t *)
spin_lock_irqsace(spinlock_t *，unsigned long flags)
spin_unlock_irqsace(spinlock_t *, unsigned long flags)
spin_trylock(spinlock_t *)
spin_is_locked(spinlock_t *)
• 初始化
spinlock有兩種初始化形式，一種是靜態初始化，一種是動態初始化。對於靜態的spinlock對象，我們用 SPIN_LOCK_UNLOCKED來初始化，它是一個宏。當然，我們也可以把聲明spinlock和初始化它放在一起做，這就是 DEFINE_SPINLOCK宏的工作，因此，下面的兩行代碼是等價的。
DEFINE_SPINLOCK (lock);
spinlock_t lock = SPIN_LOCK_UNLOCKED;
spin_lock_init 函數一般用來初始化動態創建的spinlock_t對象，它的參數是一個指向spinlock_t對象的指針。當然，它也可以初始化一個靜態的沒有初始化的spinlock_t對象。
spinlock_t *lock
......
spin_lock_init(lock);
• 獲取鎖
內核提供了三個函數用於獲取一個自旋鎖。
spin_lock：獲取指定的自旋鎖。
spin_lock_irq：禁止本地中斷並獲取自旋鎖。
spin_lock_irqsace：保存本地中斷狀態，禁止本地中斷並獲取自旋鎖，返回本地中斷狀態。
自旋鎖是可以使用在中斷處理程序中的，這時需要使用具有關閉本地中斷功能的函數，我們推薦使用 spin_lock_irqsave，因為它會保存加鎖前的中斷標志，這樣就會正確恢復解鎖時的中斷標志。如果spin_lock_irq在加鎖時中斷是關閉的，那麼在解鎖時就會錯誤的開啟中斷。
另外兩個同自旋鎖獲取相關的函數是：
spin_trylock()：嘗試獲取自旋鎖，如果獲取失敗則立即返回非0值，否則返回0。
spin_is_locked()：判斷指定的自旋鎖是否已經被獲取了。如果是則返回非0，否則，返回0。
• 釋放鎖
同獲取鎖相對應，內核提供了三個相對的函數來釋放自旋鎖。
spin_unlock：釋放指定的自旋鎖。
spin_unlock_irq：釋放自旋鎖並激活本地中斷。
spin_unlock_irqsave：釋放自旋鎖，並恢復保存的本地中斷狀態。
五、讀寫自旋鎖
如 果臨界區保護的數據是可讀可寫的，那麼只要沒有寫操作，對於讀是可以支持並發操作的。對於這種只要求寫操作是互斥的需求，如果還是使用自旋鎖顯然是無法滿 足這個要求（對於讀操作實在是太浪費了）。為此內核提供了另一種鎖－讀寫自旋鎖，讀自旋鎖也叫共享自旋鎖，寫自旋鎖也叫排他自旋鎖。
讀寫自旋鎖是一種比自旋鎖粒度更小的鎖機制，它保留了「自旋」的概念，但是在寫操作方面，只能最多有一個寫進程，在讀操作方面，同時可以有多個讀執行單元，當然，讀和寫也不能同時進行。
讀寫自旋鎖的使用也普通自旋鎖的使用很類似，首先要初始化讀寫自旋鎖對象：
// 靜態初始化
rwlock_t rwlock = RW_LOCK_UNLOCKED;
//動態初始化
rwlock_t *rwlock;
...
rw_lock_init(rwlock);
在讀操作代碼里對共享數據獲取讀自旋鎖：
read_lock(&rwlock);
...
read_unlock(&rwlock);
在寫操作代碼里為共享數據獲取寫自旋鎖：
write_lock(&rwlock);
...
write_unlock(&rwlock);
需要注意的是，如果有大量的寫操作，會使寫操作自旋在寫自旋鎖上而處於寫飢餓狀態（等待讀自旋鎖的全部釋放），因為讀自旋鎖會自由的獲取讀自旋鎖。
讀寫自旋鎖的函數類似於普通自旋鎖，這里就不一一介紹了，我們把它列在下面的表中。
RW_LOCK_UNLOCKED
rw_lock_init(rwlock_t *)
read_lock(rwlock_t *)
read_unlock(rwlock_t *)
read_lock_irq(rwlock_t *)
read_unlock_irq(rwlock_t *)
read_lock_irqsave(rwlock_t *, unsigned long)
read_unlock_irqsave(rwlock_t *, unsigned long)
write_lock(rwlock_t *)
write_unlock(rwlock_t *)
write_lock_irq(rwlock_t *)
write_unlock_irq(rwlock_t *)
write_lock_irqsave(rwlock_t *, unsigned long)
write_unlock_irqsave(rwlock_t *, unsigned long)
rw_is_locked(rwlock_t *)
六、順序瑣
順序瑣（seqlock）是對讀寫鎖的一種優化，若使用順序瑣，讀執行單元絕不會被寫執行單元阻塞，也就是說，讀執行單元可以在寫執行單元對被順序瑣保護的共享資源進行寫操作時仍然可以繼續讀，而不必等待寫執行單元完成寫操作，寫執行單元也不需要等待所有讀執行單元完成讀操作才去進行寫操作。
但是，寫執行單元與寫執行單元之間仍然是互斥的，即如果有寫執行單元在進行寫操作，其它寫執行單元必須自旋在哪裡，直到寫執行單元釋放了順序瑣。
如果讀執行單元在讀操作期間，寫執行單元已經發生了寫操作，那麼，讀執行單元必須重新讀取數據，以便確保得到的數據是完整的，這種鎖在讀寫同時進行的概率比較小時，性能是非常好的，而且它允許讀寫同時進行，因而更大的提高了並發性，
注意，順序瑣由一個限制，就是它必須被保護的共享資源不含有指針，因為寫執行單元可能使得指針失效，但讀執行單元如果正要訪問該指針，將導致Oops。
七、信號量
Linux中的信號量是一種睡眠鎖，如果有一個任務試圖獲得一個已經被佔用的信號量時，信號量會將其推進一個等待隊列，然後讓其睡眠，這時處理器能重獲自由，從而去執行其它代碼，當持有信號量的進程將信號量釋放後，處於等待隊列中的哪個任務被喚醒，並獲得該信號量。
信號量，或旗標，就是我們在操作系統里學習的經典的P/V原語操作。
P：如果信號量值大於0，則遞減信號量的值，程序繼續執行，否則，睡眠等待信號量大於0。
V：遞增信號量的值，如果遞增的信號量的值大於0，則喚醒等待的進程。
信號量的值確定了同時可以有多少個進程可以同時進入臨界區，如果信號量的初始值始1，這信號量就是互斥信號量（MUTEX）。對於大於1的非0值信號量，也可稱為計數信號量（counting semaphore）。對於一般的驅動程序使用的信號量都是互斥信號量。
類似於自旋鎖，信號量的實現也與體系結構密切相關，具體的實現定義在頭文件中，對於x86_32系統來說，它的定義如下：
struct semaphore {
atomic_t count;
int sleepers;
wait_queue_head_t wait;
};
信號量的初始值count是atomic_t類型的，這是一個原子操作類型，它也是一個內核同步技術，可見信號量是基於原子操作的。我們會在後面原子操作部分對原子操作做詳細介紹。
信號量的使用類似於自旋鎖，包括創建、獲取和釋放。我們還是來先展示信號量的基本使用形式：
static DECLARE_MUTEX(my_sem);
......
if (down_interruptible(&my_sem))
{
return -ERESTARTSYS;
}
......
up(&my_sem)
Linux內核中的信號量函數介面如下：
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
seam_init(struct semaphore *, int);
init_MUTEX(struct semaphore *);
init_MUTEX_LOCKED(struct semaphore *)
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
• 初始化信號量
信號量的初始化包括靜態初始化和動態初始化。靜態初始化用於靜態的聲明並初始化信號量。
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
對於動態聲明或創建的信號量，可以使用如下函數進行初始化：
seam_init(sem, count);
init_MUTEX(sem);
init_MUTEX_LOCKED(struct semaphore *)
顯然，帶有MUTEX的函數始初始化互斥信號量。LOCKED則初始化信號量為鎖狀態。
• 使用信號量
信號量初始化完成後我們就可以使用它了
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
down函數會嘗試獲取指定的信號量，如果信號量已經被使用了，則進程進入不可中斷的睡眠狀態。down_interruptible則會使進程進入可中斷的睡眠狀態。關於進程狀態的詳細細節，我們在內核的進程管理里在做詳細介紹。
down_trylock嘗試獲取信號量， 如果獲取成功則返回0，失敗則會立即返回非0。
當退出臨界區時使用up函數釋放信號量，如果信號量上的睡眠隊列不為空，則喚醒其中一個等待進程。
八、讀寫信號量
類似於自旋鎖，信號量也有讀寫信號量。讀寫信號量API定義在頭文件中，它的定義其實也是體系結構相關的，因此具體實現定義在頭文件中，以下是x86的例子：
struct rw_semaphore {
signed long count;
spinlock_t wait_lock;
struct list_head wait_list;
};
Ⅵ Linux內核頭文件
#include <linux/mole.h>:模塊
#include <linux/kernel.h>:內核
#include <linux/sched.h>:調度器
#include <linux/signal.h>：信號量
#include <linux/errno.h>:裡面定義一些「錯誤」信息
#include <linux/fcntl.h>:file control
#include <linux/spinlock.h>:環行鎖,實現臨界區的互斥訪問
其他的我不是很清楚，你可以去google一下.
Ⅶ linux自旋鎖使用時需要注意的幾個地方
1、在內核多線程編程時，為了保護共享資源通常需要使用鎖，而使用的比較多的就是spinlock，但需要注意的是：所有臨界區代碼都需要加鎖保護，否則就達不到保護效果。也就是，訪問共享資源的多個線程需要協同工作共同加鎖才能保證不出錯。在實際寫代碼時，有時候會網掉這一點，以致出現各種稀奇古怪的問題，而且很難找到原因。
2、在出現兩個和多個自旋鎖的嵌套使用時，務必注意加鎖和解鎖的順序。
比如：在線程1中，spinlock A -> spinlock B -> spin unlock B -> spin unlock A ；那麼，在需要同步的線程2中，若需要加相同的鎖，則順序也應該保持相同，spinlock A -> spinlock B -> spin unlock B -> spin unlock A ；否則，很有可能出現死鎖。
3、spinlock保護的代碼執行時間要盡量短，若有for循環之類的代碼，則一定要確保循環可以在短時間可以退出，從而使得spinlock可以釋放。
4、spinlock所保護的代碼在執行過程中不能睡眠。比如，在spinlock和spinunlock之間不能調用kmalloc, _from_user,kthread_stop等調用，因為這些函數調用均有可能導致線程睡眠。
5、spinlock在實際使用時有如下幾種類型，spin_lock，spin_lock_bh，spin_lock_irqsave。在具體使用時，需要根據被保護臨界區鎖處的上下文選擇合適的spinlock類型。
spin_lock用於不同cpu線程間同步，spin_lock_bh和spin_lock_irqsave主要用於本cpu線程間的同步，前者關軟中斷，後者關硬中斷。
Ⅷ 如何調用spin_lock函數
linux/spinlock.h是系統編程（包括驅動程序的編寫）中用到的頭文件。應用程序只能通過系統調用來使用內核提供的功能。
Ⅸ Linux下各種鎖的理解和使用及總結解決epoll驚群問題(面試常考)-
鎖出現的原因
臨界資源是什麼: 多線程執行流所共享的資源
鎖的作用是什麼, 可以做原子操作, 在多線程中針對臨界資源的互斥訪問... 保證一個時刻只有一個線程可以持有鎖對於臨界資源做修改操作...
任何一個線程如果需要修改，向臨界資源做寫入操作都必須持有鎖，沒有持有鎖就不能對於臨界資源做寫入操作.
鎖 ： 保證同一時刻只能有一個線程對於臨界資源做寫入操作 (鎖地功能)
再一個直觀地代碼引出問題，再從指令集的角度去看問題
上述一個及其奇怪的結果，這個結果每一次運行都可能是不一樣的，Why ？ 按照我們本來的想法是每一個線程 + 20000000 結果肯定應該是60000000呀，可以就是達不到這個值
為何？ (深入匯編指令來看) 一定將過程放置到匯編指令上去看就可以理解這個過程了.
a++; 或者 a += 1; 這些操作的匯編操作是幾個步驟?
其實是三個步驟：
正常情況下，數據少，操作的線程少，問題倒是不大，想一想要是這樣的情況下，操作次數大，對齊操作的線程多，有些線程從中間切入進來了，在運算之後還沒寫回內存就另外一個線程切入進來同時對於之前的數據進行++ 再寫回內存, 啥效果，多次++ 操作之後結果確實一次加加操作後的結果。 這樣的操作 (術語叫做函數的重入) 我覺得其實就是重入到了匯編指令中間了，還沒將上一次運算的結果寫回內存就重新對這個內存讀取再運算寫入，結果肯定和正常的邏輯後的結果不一樣呀
來一幅圖片解釋一下
咋辦? 其實問題很清楚，我們只需要處理的是多條匯編指令不能讓它中間被插入其他的線程運算. （要想自己在執行匯編指令的時候別人不插入進來） 將多條匯編指令綁定成為一條指令不就OK了嘛。
也就是原子操作！！！
不會原子操作？操作系統給咱提供了線程的 綁定方式工具呀：mutex 互斥鎖(互斥量)， 自旋鎖(spinlock)， 讀寫鎖（readers-writer lock） 他們也稱作悲觀鎖. 作用都是一個樣，將多個匯編指令鎖成為一條原子操作 (此處的匯編指令也相當於如下的臨界資源)
悲觀鎖：鎖如其名，每次都悲觀地認為其他線程也會來修改數據，進行寫入操作，所以會在取數據前先加鎖保護，當其他線程想要訪問數據時，被阻塞掛起
樂觀鎖：每次取數據的時候，總是樂觀地認為數據不會被其他線程修改，因此不上鎖。但是在更新數據前， 會判斷其他數據在更新前有沒有對數據進行修改。
互斥鎖
最為常見使用地鎖就是互斥鎖, 也稱互斥量. mutex
特徵，當其他線程持有互斥鎖對臨界資源做寫入操作地時候，當前線程只能掛起等待，讓出CPU，存在線程間切換工作
解釋一下存在線程間切換工作 : 當線程試圖去獲取鎖對臨界資源做寫入操作時候，如果鎖被別的線程正在持有，該線程會保存上下文直接掛起，讓出CPU，等到鎖被釋放出來再進行線程間切換，從新持有CPU執行寫入操作
互斥鎖需要進行線程間切換，相比自旋鎖而言性能會差上許多，因為自旋鎖不會讓出CPU, 也就不需要進行線程間切換的步驟，具體原理下一點詳述
加互斥量(互斥鎖)確實可以達到要求，但是會發現運行時間非常的長，因為線程間不斷地切換也需要時間, 線程間切換的代價比較大.
相關視頻推薦
你繞不開的組件—鎖，4個方面手撕鎖的多種實現
「驚群」原理、鎖的設計方案及繞不開的「死鎖」問題
學習地址：C/C++Linux伺服器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂
需要C/C++ Linux伺服器架構師學習資料加qun812855908獲取（資料包括 C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg 等），免費分享
自旋鎖
spinlock.自旋鎖.
對比互斥量(互斥鎖)而言，獲取自旋鎖不需要進行線程間切換，如果自旋鎖正在被別的線程佔用，該線程也不會放棄CPU進行掛起休眠，而是恰如其名的在哪裡不斷地循環地查看自旋鎖保持者(持有者)是否將自旋鎖資源釋放出來... （自旋地原來就是如此）
口語解釋自旋：持有自旋鎖的線程不釋放自旋鎖，那也沒有關系呀，我就在這里不斷地一遍又一遍地查詢自旋鎖是否釋放出來，一旦釋放出來我立馬就可以直接使用 (因為我並沒有掛起等待，不需要像互斥鎖還需要進行線程間切換，重新獲取CPU，保存恢復上下文等等操作)
哪正是因為上述這些特點，線程嘗試獲取自旋鎖，獲取不到不會採取休眠掛起地方式，而是原地自旋（一遍又一遍查詢自旋鎖是否可以獲取）效率是遠高於互斥鎖了. 那我們是不是所有情況都使用自旋鎖就行了呢，互斥鎖就可以放棄使用了嗎????
解釋自旋鎖地弊端：如果每一個線程都僅僅只是需要短時間獲取這個鎖，那我自旋占據CPU等待是沒啥問題地。要是線程需要長時間地使用占據（鎖）。。。 會造成過多地無端占據CPU資源，俗稱站著茅坑不拉屎... 但是要是僅僅是短時間地自旋，平衡CPU利用率 + 程序運行效率 （自旋鎖確實是在有些時候更加合適）
自旋鎖需要場景：內核可搶占或者SMP(多處理器)情況下才真正需求 (避免死鎖陷入死循環，瘋狂地自旋，比如遞歸獲取自旋鎖. 你獲取了還要獲取，但是又沒法釋放)
自旋鎖的使用函數其實和互斥鎖幾乎是一摸一樣地，僅僅只是需要將所有的mutex換成spin即可
僅僅只是在init存在些許不同
何為驚群，池塘一堆, 我瞄準一條插過去，但是好似所有的都像是覺著自己正在被插一樣的四處逃竄。 這個就是驚群的生活一點的理解
驚群現象其實一點也不少，比如說 accept pthread_cond_broadcast 還有多個線程共享epoll監視一個listenfd 然後此刻 listenfd 說來 SYN了，放在了SYN隊列中，然後完成了三次握手放在了 accept隊列中了, 現在問題是這個connect我應該交付給哪一個線程處理呢.
多個epoll監視准備工作的線程 就是這群 ()，然後connet就是魚叉，這一叉下去肯定是所有的 epoll線程都會被驚醒 (多線程共享listenfd引發的epoll驚群)
同樣如果將上述的多個線程換成多個進程共享監視 同一個 listenfd 就是(多進程的epoll驚群現象)
咱再畫一個草圖再來理解一下這個驚群:
如果是多進程道理是一樣滴，僅僅只是將所有的線程換成進程就OK了
終是來到了今天的正題了: epoll驚群問題地解決上面了...
首先 先說說accept的驚群問題，沒想到吧accept 平時大家寫它的多線程地時候，多個線程同時accept同一個listensock地時候也是會存在驚群問題地，但是accept地驚群問題已經被Linux內核處理了: 當有新的連接進入到accept隊列的時候，內核喚醒且僅喚醒一個進程來處理
但是對於epoll的驚群問題，內核卻沒有直接進行處理。哪既然內核沒有直接幫我們處理，我們應該如何針對這種現象做出一定的措施呢?
驚群效應帶來的弊端: 驚群現象會造成epoll的偽喚醒，本來epoll是阻塞掛起等待著地，這個時候因為掛起等待是不會佔用CPU地。。。 但是一旦喚醒就會佔用CPU去處理發生地IO事件， 但是其實是一個偽喚醒，這個就是對於線程或者進程的無效調度。然而進程或者線程地調取是需要花費代價地，需要上下文切換。需要進行進程(線程)間的不斷切換... 本來多核CPU是用來支持高並發地，但是現在卻被用來無效地喚醒，對於多核CPU簡直就是一種浪費 （浪費系統資源） 還會影響系統的性能.
解決方式（一般是兩種）
Nginx的解決方式:
加鎖：驚群問題發生的前提是多個進程（線程）監聽同一個套接字(listensock)上的事件，所以我們只讓一個進程（線程）去處理監聽套接字就可以了。
畫兩張圖來理解一下：
上述還沒有進行一個每一個進程都對應一個listensock 而是多線程共享一個listensock 運行結果如下
所有的線程同時被喚醒了，但是實際上會處理連接的僅僅只是一個線程，
咱僅僅只是將主線程做如上這樣一個簡單的修改，每一個線程對應一個listensock；每一個線程一個獨有的監視窗口，將問題拋給內核去處理，讓內核去負載均衡 ： 結果如下
僅僅喚醒一個線程來進行處理連接，解決了驚群問題
本文通過介紹兩種鎖入手，以及為什麼需要鎖，鎖本質就是為了保護，持有鎖你就有權力有能力操作寫入一定的臨界保護資源，沒有鎖你就不行需要等待，本質其實是將多條匯編指令綁定成原子操作
然後介紹了驚群現象，通過一個巧妙地例子，扔一顆石子，只是瞄準一條魚扔過去了，但是整池魚都被驚醒了，
對應我們地實際問題就是， 多個線程或者進程共同監視同一個listensock。。。。然後IO連接事件到來地時候本來僅僅只是需要一個線程醒過來處理即可，但是卻會使得所有地線程（進程）全部醒過來，造成不必要地進程線程間切換，多核CPU被浪費喔，系統資源被浪費
處理方式 一。 Nginx 源碼加互斥鎖處理。。 二。設置SO_REUSEPORT, 使得多個進程線程可以同時連接同一個port , 為每一個進程線程搞一個listensock... 將問題拋給內核去處理，讓他去負載均衡地僅僅將IO連接事件分配給一個進程或線程