假設這樣一種情況：有多個執行緒（或多核）需要在共享資料A滿足某一條件時,對A進行操作.

以下舉例兩種實現

Fun_1()

{ lock()--------------1.1

  Result=Check(A)-----1.2

  Unlock()------------1.3

                     -------------RISK!!!!

  Lock()--------------1.4

  Operate(A,result)---1.5

  Unlock()------------1.6

}

Fun_2()

{ lock()--------------2.1

  Result=Check(A)-----2.2

  Operate(A,result)---2.3

  Unlock()------------2.4

}

以上函式，只有fun_2 是安全的，FUN_1存在風險：

單核下：

當前執行緒完1.3   後如果發生了執行緒排程，那麼資料a可能被其它執行緒修改。

重新回到1.4時，RESULT 已經不對了！！！

多核下：

當前執行緒完1.3   後如果發生了執行緒排程，那麼資料a可能被其它執行緒修改。

重新回到1.4時，RESULT 已經不對了！！！

當前執行緒完1.3   後如果第二個核正好在執行程式碼1.5，那麼資料a會被修改。

重新回到1.4時，RESULT 已經不對了！！！

***********************************************************************************************

鎖的選擇分為“訊號量”“和自旋轉鎖”：

訊號量會使程式休眠

自旋鎖會關搶佔，並進行忙等待

一般如果訪問時間較短，或者使用多核處理器可以選擇自旋鎖

如果訪問的時間較長（大於系統進行兩次排程需要的時間）且是單核處理器，則可以選擇訊號量。

************************************************************************************************

linux下自旋鎖函式：

spin_lock                                       使用情況：如果被保護的共享資源“只在程序上下文訪問”    

                                                        功能：        最基本的鎖，沒有對中斷處理

spin_lock_bh                                適用情況：如果被保護的共享資源“只在程序上下文和tasklet或timer上下文訪問”

                                                        功能：        spin_lock為基礎，釋放時開啟上鎖時禁止的軟中斷

spin_lock_irq                                適用情況：如果被保護的共享資源“只在程序上下文和tasklet或timer上下文訪問”

                                                        功能：        spin_lock為基礎，釋放時開啟中斷

spin_lock_irqsave                       適用情況：效率最差的一種，但當你不知道用哪個好時，可以用它

                                                        功能：        spin_lock為基礎，釋放時恢復上鎖時的中斷狀態

*******************************************************************************************************************

以下說明摘自網上：

如果被保護的共享資源“只在程序上下文訪問和軟中斷上下文訪問”，那麼當在程序上下文訪問共享資源時，可能被軟中斷打斷，從而可能進入軟中斷上下文來對被保護的共享資源訪問，因此對於這種情況，對共享資源的訪問必須使用spin_lock_bh和spin_unlock_bh來保護。