欧美久久成人,黄色av免费在线,亚洲福利电影网

一、前言

談到『自旋鎖』，可能大家會說，這有啥好講的，不就是等待資源的線程"原地打轉"嘛。嗯，字面理解的意思很到位，但能深入具體點嗎？自旋鎖的設計真就這么簡單？

本文或者說本系列的目的，都是讓大家不要停留在表面，而是深入分析，做到：

靈活使用
掌握原理
優缺點

二、鎖的優化：自旋鎖

當多個線程想同時訪問同一個資源時，就存在資源沖突，這時，大家最直接想到的就是加鎖來互斥訪問，加鎖會有這么幾個問題：

等待資源的線程進入睡眠，發生用戶態向內核態的切換，有一定的性能開銷；
占用資源的線程很快就用完并釋放，這時等待的線程被喚醒，又要立即切換回用戶態；

那么，如果有一種方式，使得等待的線程先短暫的等待一會兒，有可能有兩種結果：

等待的時間超過了這一會兒，那沒辦法，只好進入睡眠；
等待的時間還未超過，占用資源的線程釋放了，這時等待的線程就可以直接占用資源。

這就是鎖的小優化：自旋鎖！自旋鎖并不是真正的鎖，而是讓等待的線程先原地"小轉"一下，小轉一下，通常小轉一下的實現方式很簡單：

				?

									int SPIN_LOCK_NUM = 64;

									int i = 0;

									boolean wait = true;

									do {

									 wait = // 嘗試獲取資源鎖

									} while (wait && (++i) < SPIN_LOCK_NUM);

我們通過循環一定的次數來自旋。 \color{red}{但是我們也應該知道，不進入休眠而原地打轉，是會一直消耗 CPU 資源的，因此，才有了自旋限制！}但是我們也應該知道，不進入休眠而原地打轉，是會一直消耗CPU資源的，因此，才有了自旋限制！

看下面的JDK源碼：

				?

									public final class Unsafe {

									 public final int getAndSetInt(Object var1, long var2, int var4) {

									  int var5;

									  do {

									   var5 = this.getIntVolatile(var1, var2);

									  } while(!this.compareAndSwapInt(var1, var2, var5, var4));

									  return var5;

									 }

									}

我們可以看到，CAS就是采用的自旋鎖方式，持續的嘗試讀取最新的 volatile 修飾的變量的值，并嘗試去用期望的值去比較，然后更新。

不過這里我們要注意，因為是無限循環，因此我們要保證占用資源的線程很快就能釋放，而不是長時間占用（當然，因為這里的源碼系統也設定了 int 型變量，因此，占用該變量的線程很快就會使用完而釋放）。

三、自旋鎖的死鎖

啥？怎么會有死鎖？自旋鎖雖然好用，若我們只是停留在上面的分析，那么還是很膚淺的；雖然自旋鎖有很大的優勢，但同樣缺點也不少，除了上面說的，原地打轉（忙等待）會一直消耗CPU資源，同時，還會有一個潛在的可能缺陷：死鎖。

3.1、系統中斷

在聊死鎖之前，我們需要先了解一下系統中斷事件（大學課本里有這一章節，ASM匯編中也涉及到系統中斷向量表）：

中斷是指，CPU正常運行期間，由于有內/外部事件，或者由程序預先安排的事件，引起CPU暫停當前工作，轉而去處理該事件，當處理完該事件后再返回繼續運行被中斷（暫停）的程序。通常，操作系統將中斷分為兩類：外部中斷（硬件中斷）和內部中斷（異常中斷，即軟件引起的）；

例如：由IO設備引起的中斷為硬件中斷，比如，鍵盤輸入，硬盤/光驅讀寫等；異常中斷很好理解，比如 NullPointerException 等。

3.2、中斷處理程序

系統提供了一個API使得我們的程序能夠向系統申請注冊一個中斷處理程序（例如：程序接收用戶的輸入事件）。

				?

									request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev)

參數含義如下：

irq: 中斷號，系統定義好，具體可查看中斷向量表；
handler: 中斷后發生的ISR（Interrupt Service Routines），直接翻譯為：中斷服務路由；實際類似，是響應中斷服務的程序；
flags: 中斷標志；
name: 中斷相關的設備的ASCII，如："keyboard"，這些名字會在 /proc/irq 和 /proc/interrupts 中使用；
dev: 用于共享中斷線，傳遞驅動程序的設備結構。非共享類型的中斷，直接設置成為 NULL

中斷標志（flags）：

IRQF_DISABLED：內核處理該ISR期間，禁止其它中斷（一般很少使用）；
IRQF_SAMPLE_RANDOM：表明該設備產生的中斷對內核熵池有貢獻；
IRQF_TIMER：系統定時器；
IRQF_SHARED：多個ISR共享中斷線，即一個中斷，可存在多個ISR；

調用 request_irq 成功時返回0，常見錯誤是 -EBUSY，表示給定的中斷線已經在使用（沒有指定IRQF_SHARED）。

注：

該函數可能引起睡眠，所以不允許在中斷上下文或者不允許睡眠的程序中使用！
Linux 中的中斷處理程序是無須重入的。當給定的中斷處理程序正在執行的時候，其中斷線在所有的處理器上都會被屏蔽掉，以防在同一個中斷線上又接收到另一個新的中斷。通常情況下，除了該中斷的其他中斷都是打開的，也就是說其他的中斷線上的重點都能夠被處理，但是當前的中斷線總是被禁止的，故，同一個中斷處理程序是絕對不會被自己嵌套的。

那這和死鎖有何關系呢？額，下一小節會談到。但這里之所有提到中斷，是因為我們還要知道一件事，當系統產生中斷，程序被暫停時，程序是不能進入休眠的，此時程序只能采用一種方式：自旋，來保證不會睡眠。

為何不能睡眠？這里就涉及到『中斷上下文 context』！

3.3、中斷上下文 Context

上面說了，request_irq 可能引起睡眠，所以不允許在中斷上下文中使用，也就是說，中斷上下文不允許睡眠！

中斷上下文：它與進程上下文不一樣，中斷上下文是內核正在執行ISR。ISR沒有自己獨立的棧，而是使用內核棧，大小一般是有限制的（32位是8KB大小）。同時，ISR是打斷了正常的程序流程，因此必須保證ISR執行速度快。正因為要執行速度快，所以，中斷上下文不允許睡眠，且不允許被阻塞！

大家可能會說了，執行速度快不允許睡眠，這解釋不合理，我睡眠個1ms不行么？嗯，下面我們就來分析下不能睡眠的真正原因：

1.中斷處理時，不會發生進程切換。

因為能打斷當前中斷的只可能是更高優先級的中斷，其它進程的優先級是不會比中斷優先級更高的；
如果中斷上下文休眠，則沒有辦法喚醒它，因為所有的 wake_up_xxx 是針對進程而言，而中斷沒有進程的概念；
只要是中斷（硬中or軟中，不是香煙），都發生在內核，如果中斷上下文睡眠了，內核就阻塞了，系統能阻塞么？不能！阻塞了你就只能重啟機器了；

2.schedule 在切換進程時，會保存當前的進程上下文（CPU寄存器的值、狀態、堆棧SP內容）以便以后恢復再運行。中斷發生后，內核會保存當前被中斷進程的上下文。在ISR中，是中斷上下文，如果休眠或阻塞，則會調用 schedule，保存的進程上下文不是當前進程的上下文，所以不能在ISR中調用 schedule；
3.內核中 schedule 在進入時會判斷是否處于中斷上下文：

				?

									if(unlikely(in_interrupt()))) ..... crash!!!

4.中斷 handler 會使用被中斷的進程內核堆棧，但不會對其有任何影響，因為 handler用之前會保存，用完后會清除并恢復原貌；
5.處理中斷上下文中，內核是不可搶占的，如果休眠，則內核....一定會被掛起，同樣，你只能重啟機器了；
所以，被中斷的程序也不能睡眠！那么只能使用『自旋鎖』來原地打轉。