mutex和spin lock的區別和應用(sleep-waiting和busy-waiting的區別)2011-10-19 11:43
訊號量mutex是sleep-waiting。 就是說當沒有獲得mutex時，會有上下文切換，將自己、加到忙等待佇列中，直到另外乙個執行緒釋放mutex並喚醒它，而這時cpu是空閒的，可以排程別的任務處理。
而自旋鎖spin lock是busy-waiting。就是說當沒有可用的鎖時，就一直忙等待並不停的進行鎖請求，直到得到這個鎖為止。這個過程中cpu始終處於忙狀態，不能做別的任務。
例如在乙個雙核的機器上有兩個執行緒(執行緒a和執行緒b)，它們分別執行在core0 和core1上。 用spin-lock，coer0上的執行緒就會始終占用cpu。
另外乙個值得注意的細節是spin lock耗費了更多的user time。這就是因為兩個執行緒分別執行在兩個核上，大部分時間只有乙個執行緒能拿到鎖，所以另乙個執行緒就一直在它執行的core上進行忙等待，cpu佔用率一直是100%；而mutex則不同，當對鎖的請求失敗後上下文切換就會發生，這樣就能空出乙個核來進行別的運算任務了。（其實這種上下文切換對已經拿著鎖的那個執行緒效能也是有影響的，因為當該執行緒釋放該鎖時它需要通知作業系統去喚醒那些被阻塞的執行緒，這也是額外的開銷）
總結（1）mutex適合對鎖操作非常頻繁的場景，並且具有更好的適應性。儘管相比spin lock它會花費更多的開銷（主要是上下文切換），但是它能適合實際開發中複雜的應用場景，在保證一定效能的前提下提供更大的靈活度。
（2）spin lock的lock/unlock效能更好(花費更少的cpu指令)，但是它只適應用於臨界區執行時間很短的場景。而在實際軟體開發中，除非程式設計師對自己的程式的鎖操作行為非常的了解，否則使用spin lock不是乙個好主意(通常乙個多執行緒程式中對鎖的操作有數以萬次，如果失敗的鎖操作(contended lock requests)過多的話就會浪費很多的時間進行空等待)。
（3）更保險的方法或許是先（保守的）使用 mutex，然後如果對效能還有進一步的需求，可以嘗試使用spin lock進行調優。畢竟我們的程式不像linux kernel那樣對效能需求那麼高(linux kernel最常用的鎖操作是spin lock和rw lock)。
mutex 和spin lock的區別
在這裡推薦一本書 深入linux核心機制分析 這本書對這些講得非常好，對有基礎的朋友幫助會很大，新手建議不好要使用，因為有一種雲裡霧裡的感覺，非常的枯燥。有哪些核心鎖機制?1 原子操作 atomic t資料型別，atomic inc atomic t v 將v加1 原子操作比普通操作效率要低，因此必...
spinlock的設計和實現
在linux的核心中，spin lock用在多處理器環境中。當乙個cpu訪問乙個臨界資源 critical section 的時候，需要預先取得spin lock，如果取不到的話，它就在空迴圈 等待，直到另外的cpu釋放spin lock。由於涉及到多個處理器，spin lock的效率非常重要。因為...
Mutex 和 monitor的區別
monitor和lock多用於鎖定被呼叫端，而mutex則多用鎖定呼叫端。lock this 或者是用monitor也是一樣的，如下 monitor.enter this do something monitor.exit this monitor的好處是可以用tryenter this，timeo...