首先必須意識到：休眠是一種進程的特殊狀態（即task->state= TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE）]

一、休眠的目的

簡單的說，休眠是為在一個當前進程等待暫時無法獲得的資源或者一個event的到來時（原因），避免當前進程浪費CPU時間（目的），將自己放入進程等待隊列中，同時讓出CPU給別的進程（工作）。休眠就是為了更好地利用CPU。

一旦資源可用或event到來，將由內核代碼（可能是其他進程通過系統調用）喚醒某個等待隊列上的部分或全部進程。從這點來說，休眠也是一種進程間的同步機制。

二、休眠的對象

休眠是針對進程，也就是擁有task_struct的獨立個體。

當進程執行某個系統調用的時候，暫時無法獲得的某種資源或必須等待某event的到來，在這個系統調用的底層實現代碼就可以通過讓系統調度的手段讓出CPU，讓當前進程處于休眠狀態。

• 進程什么時候會被休眠？

? ? 進程進入休眠狀態，必然是他自己的代碼中調用了某個系統調用，而這個系統調用中存在休眠代碼。這個休眠代碼在某種條件下會被激活，從而讓改變進程狀態，說到底就是以各種方式包含了：

1、條件判斷語句

2、進程狀態改變語句

3、schedule();

三、休眠操作做了什么

進程被置為休眠，意味著它被標識為處于一個特殊的狀態（TASK_UNINTERRUPTIBLE或?TASK_INTERRUPTIBLE），并且從調度器的運行隊列中移走。這個進程將不在任何?CPU?上被調度，即不會被運行。?直到發生某些事情改變了那個狀態（to?TASK_WAKING）。這時處理器重新開始執行此進程，此時進程會再次檢查是否需要繼續休眠（資源是否真的可用？），如果不需要就做清理工作，并將自己的狀態調整為TASK_RUNNING。

四、誰來喚醒休眠進程

進程在休眠后，就不再被調度器執行，就不可能由自己喚醒自己，也就是說進程不可能“睡覺睡到自然醒”。喚醒工作必然是由其他進程或者內核本身來完成的。喚醒需要改變進程的task_struct中的狀態等，代碼必然在內核中，所以喚醒必然是在系統調用的實現代碼中（如你驅動中的read、write方法）以及各種形式的中斷代碼（包括軟、硬中斷）中。

如果在系統調用代碼中喚醒，則說明是由其他的某個進程來調用了這個系統調用喚醒了休眠的進程。

如果是中斷中喚醒，那么喚醒的任務可以說是內核完成了。

• 如何找到需要喚醒的進程：等待隊列

上面其實已經提到了：休眠代碼的一個工作就是將當前進程信息放入一個等待隊列中。它其實是一個包含等待某個特定事件的所有進程相關信息的鏈表。一個等待隊列由一個wait_queue_head_t?結構體來管理，其定義在中。

wait_queue_head_t?類型的數據結構如下：?

它包含一個自旋鎖和一個鏈表。這是一個等待隊列鏈表頭，鏈表中的元素被聲明做wait_queue_t。自旋鎖用于包含鏈表操作的原子性。?

wait_queue_t包含關于睡眠進程的信息和喚醒函數。

他們在內存中的結構大致如下圖所示：

等待隊列頭wait_queue_head_t一般是定義在模塊或內核代碼中的全局變量，而其中鏈接的元素?wait_queue_t的定義被包含在了休眠宏中。

休眠和喚醒的過程如下圖所示：

五、休眠和喚醒的代碼簡要分析

下面我們簡單分析一下休眠與喚醒的內核原語。

1、休眠：wait_event

?

?

2、喚醒：wake_up

?

上面分析的休眠函數是最簡單的休眠喚醒函數，其他類似的函數，如后綴為_timeout、_interruptible、_interruptible_timeout的函數其實都是在喚醒后的條件判斷上有些不同，多判斷一些喚醒條件而已。這里就不再贅述了。

六、使用休眠的注意事項

（1）?永遠不要在原子上下文中進入休眠，即當驅動在持有一個自旋鎖、seqlock或者?RCU?鎖時不能睡眠；關閉中斷也不能睡眠，終端例程中也不可休眠。

持有一個信號量時休眠是合法的，如果代碼在持有一個信號量時睡眠，任何其他的等待這個信號量的線程也會休眠。發生在持有信號量時的休眠必須短暫，而且決不能阻塞那個將最終喚醒你的進程。

（2）當進程被喚醒，它并不知道休眠了多長時間以及休眠時發生什么；也不知道是否另有進程也在休眠等待同一事件，且那個進程可能在它之前醒來并獲取了所等待的資源。所以不能對喚醒后的系統狀態做任何的假設，并必須重新檢查等待條件來確保正確的響應。

（3）除非確信其他進程會在其他地方喚醒休眠的進程，否則也不能睡眠。使進程可被找到意味著：需要維護一個等待隊列的數據結構。它是一個進程鏈表，其中包含了等待某個特定事件的所有進程的相關信息。

七、不可在中斷例程中休眠的原因

如果在某個系統調用中把當前進程休眠，是有明確目標的，這個目標就是過來call這個系統調用的進程（注意這個進程正在running）。

但是中斷和進程是異步的，在中斷上下文中，當前進程大部分時候和中斷代碼可能一點關系都沒有。要是在這里調用了休眠代碼，把當前進程給休眠了，那就極有可能把無關的進程休眠了。再者，如果中斷不斷到來，會殃及許多無辜的進程。

在中斷中休眠某個特定進程是可以實現的，通過內核的task_struct鏈表可以找到的，不論是根據PID還是name。但是只要這個進程不是當前進程，休眠它也可能沒有必要。可能這個進程本來就在休眠；或者正在執行隊列中但是還沒執行到，如果執行到他了可能又無須休眠了。

還有一個原因是中斷也是所謂的原子上下文，有的中斷例程中會禁止所有中斷，有的中斷例程還會使用自旋鎖等機制，在其中使用休眠也是非常危險的。?下面會介紹。

八、不可在持有自旋鎖、seqlock、RCU?鎖或關閉中斷時休眠的原因?

其實自旋鎖、seqlock、RCU?鎖或關閉中斷期間的代碼都稱為原子上下文，比較有代表性的就是自旋鎖spinlock。

對于UP系統，如果A進程在擁有spinlock時休眠，這個進程在擁有自旋鎖后主動放棄了處理器。其他的進程就開始使用處理器，只要有一個進程B去獲取同一個自旋鎖，B必然無法獲取，并做所謂的自旋等待。由于自旋鎖禁止所有中斷和搶占，B的自旋等待是不會被打斷的，并且B也永遠獲得不了鎖。因為B在CPU中運行，沒有其他進程可以運行并喚醒A并釋放鎖。系統就此鎖死，只能復位了。

對于SMP系統，如果A進程在擁有spinlock時休眠，這個進程在擁有自旋鎖后主動放棄了處理器。如果所有處理器都為了獲取這個鎖而自旋等待，由于自旋鎖禁止所有中斷和搶占，，就不會有進程可能去喚醒A了，系統也就鎖死了。

并不是所一旦系統獲得自旋鎖休眠就會死，而是有這個可能。但是注意了計算機的運行速度之快，只要有億分之一的可能，也是很容易發生

所有的原子上下文都有這樣的共性：不可在其中休眠，否則系統極有可能鎖死。

只要對其設備節點做兩次讀寫操作，系統必死。我在X86?的SMP系統，ARMv5、ARMv6、ARMv7中都做了如下的實驗（單核(UP)系統必須配置CONFIG_DEBUG_SPINLOCK，否則自旋鎖是沒有實際效果（起碼不會有“自旋”）， 系統可以多次獲取自旋鎖，沒有實驗效果。之后博文中有詳細描述）。現象都和上面敘述的死法相同，看了源碼就知道（關鍵在readwrite方法）。以下是實驗記錄：

?