Linux 進程的睡眠和喚醒

在 Linux 中，僅等待 CPU 時間的進程稱爲就緒進程，它們被放置在一個運行隊列中，一個就緒進程的狀 態標誌位爲 TASK_RUNNING。一旦一個運行中的進程時間片用完， Linux 內核的調度器會剝奪這個進程對 CPU 的控制權，並且從運行隊列中選擇一個合適的進程投入運行。

當然，一個進程也可以主動釋放 CPU 的控制權。函數 schedule() 是一個調度函數，它可以被一個進程主動調用，從而調度其它進程佔用 CPU。一旦這個主動放棄 CPU 的進程被重新調度佔用 CPU，那麼它將從上次停止執行的位置開始執行，也就是說它將從調用 schedule() 的下一行代碼處開始執行。

有時候，進程需要等待直到某個特定的事件發生，例如設備初始化完成、I/O 操作完成或定時器到時等。在這種情況下，進程則必須從運行隊列移出，加入到一個等待隊列中，這個時候進程就進入了睡眠狀態。

Linux 中的進程睡眠狀態有兩種：

可中斷的睡眠狀態的進程會睡眠直到某個條件變爲真，比如說產生一個硬件中斷、釋放 進程正在等待的系統資源或是傳遞一個信號都可以是喚醒進程的條件。不可中斷睡眠狀態與可中斷睡眠狀態類似，但是它有一個例外，那就是把信號傳遞到這種睡眠 狀態的進程不能改變它的狀態，也就是說它不響應信號的喚醒。不可中斷睡眠狀態一般較少用到，但在一些特定情況下這種狀態還是很有用的，比如說：進程必須等 待，不能被中斷，直到某個特定的事件發生。

在現代的 Linux 操作系統中，進程一般都是用調用 schedule() 的方法進入睡眠狀態的，下面的代碼演示瞭如何讓正在運行的進程進入睡眠狀態。

sleeping_task = current;
set_current_state(TASK_INTERRUPTIBLE);
schedule();
func1();
/* Rest of the code ... */

在第一個語句中，程序存儲了一份進程結構指針 sleeping_task，current 是一個宏，它指向正在執行的進程結構。微信搜索公衆號：Linux 開源社區，回覆：黑客 領取資料 。

set_current_state() 將該進程的狀態從執行狀態 TASK_RUNNING 變成睡眠狀態 TASK_INTERRUPTIBLE。如果 schedule() 是被一個狀態爲 TASK_RUNNING 的進程調度，那麼 schedule() 將調度另外一個進程佔用 CPU。

如果 schedule() 是被一個狀態爲 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 的進程調度，那麼還有一個附加的步驟將被執行：當前執行的進程在另外一個進程被調度之前會被從運行隊列中移出，這將導致正在運行的那個進程進入睡眠，因爲它已經不在運行隊列中了。

我們可以使用下面的這個函數將剛纔那個進入睡眠的進程喚醒。

wake_up_process(sleeping_task);

在調用了 wake_up_process() 以後，這個睡眠進程的狀態會被設置爲 TASK_RUNNING，而且調度器會把它加入到運行隊列中去。當然，這個進程只有在下次被調度器調度到的時候才能真正地投入運行。

無效喚醒

幾乎在所有的情況下，進程都會在檢查了某些條件之後，發現條件不滿足才進入睡眠。可是有的時候進程卻會在判定條件爲真後開始睡眠，如果這樣的話進程就會無限期地休眠下去，這就是所謂的無效喚醒問題。

在操作系統中，當多個進程都企圖對共享數據進行某種處理，而 最後的結果又取決於進程運行的順序時，就會發生競爭條件，這是操作系統中一個典型的問題，無效喚醒恰恰就是由於競爭條件導致的。

設想有兩個進程 A 和 B，A 進程正在處理一個鏈表，它需要檢查這個鏈表是否爲空，如果不空就對鏈表裏面的數據進行一些操作，同時 B 進程也在往這個鏈表添加節點。當這個鏈表是空的時候，由於無數據可操作，這時 A 進程就進入睡眠，當 B 進程向鏈表裏面添加了節點之後它就喚醒 A 進程，其代碼如下：

A 進程:
1 spin_lock(&list_lock);
2 if (list_empty(&list_head)) {
3     spin_unlock(&list_lock);
4     set_current_state(TASK_INTERRUPTIBLE);
5     schedule();
6     spin_lock(&list_lock);
7 }
8
9 /* Rest of the code ... */
10 spin_unlock(&list_lock);
B 進程:
100 spin_lock(&list_lock);
101 list_add_tail(&list_head, new_node);
102 spin_unlock(&list_lock);
103 wake_up_process(processa_task);

這裏會出現一個問題，假如當 A 進程執行到第 3 行後第 4 行前的時候，B 進程被另外一個處理器調度投入運行。在這個時間片內，B 進程執行完了它所有的指令，因此它試圖喚醒 A 進程，而此時的 A 進程還沒有進入睡眠，所以喚醒操作無效。

在這之後，A 進程繼續執行，它會錯誤地認爲這個時候鏈表仍然是空的，於是將自己的狀態設置爲 TASK_INTERRUPTIBLE 然後調用 schedule() 進入睡 眠。由於錯過了 B 進程喚醒，它將會無限期的睡眠下去，這就是無效喚醒問題，因爲即使鏈表中有數據需要處理，A 進程也還是睡眠了。

避免無效喚醒

如何避免無效喚醒問題呢？

我們發現無效喚醒主要發生在檢查條件之後和進程狀態被設置爲睡眠狀態之前，本來 B 進程的 wake_up_process() 提供了一次將 A 進程狀態置爲 TASK_RUNNING 的機會，可惜這個時候 A 進程的狀態仍然是 TASK_RUNNING，所以 wake_up_process() 將 A 進程狀態從睡眠狀態轉變爲運行狀態的努力 沒有起到預期的作用。

要解決這個問題，必須使用一種保障機制使得判斷鏈表爲空和設置進程狀態爲睡眠狀態成爲一個不可分割的步驟纔行，也就是必須消除競爭條 件產生的根源，這樣在這之後出現的 wake_up_process() 就可以起到喚醒狀態是睡眠狀態的進程的作用了。

找到了原因後，重新設計一下 A 進程的代碼結構，就可以避免上面例子中的無效喚醒問題了。

A 進程:
1 set_current_state(TASK_INTERRUPTIBLE);
2 spin_lock(&list_lock);
3 if (list_empty(&list_head)) {
4     spin_unlock(&list_lock);
5     schedule();
6     spin_lock(&list_lock);
7 }
8 set_current_state(TASK_RUNNING);
9
10 /* Rest of the code ... */
11 spin_unlock(&list_lock);

可以看到，這段代碼在測試條件之前就將當前執行進程狀態轉設置成 TASK_INTERRUPTIBLE 了，並且在鏈表不爲空的情況下又將自己置爲 TASK_RUNNING 狀態。

這樣一來如果 B 進程在 A 進程進程檢查了鏈表爲空以後調用 wake_up_process()，那麼 A 進程的狀態就會自動由原來 TASK_INTERRUPTIBLE 變成 TASK_RUNNING，此後即使進程又調用了 schedule()，由於它現在的狀態是 TASK_RUNNING，所以仍然不會被從運行隊列中移出，因而不會錯誤的進入睡眠，當然也就避免了無效喚醒問題。

Linux 內核的例子

在 Linux 操作系統中，內核的穩定性至關重要，爲了避免在 Linux 操作系統內核中出現無效喚醒問題，Linux 內核在需要進程睡眠的時候應該使用類似如下的操作：

/* q 是我們希望睡眠的等待隊列 */
DECLARE_WAITQUEUE(wait, current);
add_wait_queue(q, &wait);
set_current_state(TASK_INTERRUPTIBLE);
/* condition 是等待的條件 */
while (!condition) {
    schedule();
}
set_current_state(TASK_RUNNING);
remove_wait_queue(q, &wait);

上面的操作，使得進程通過下面的一系列步驟安全地將自己加入到一個等待隊列中進行睡眠：首先調用 DECLARE_WAITQUEUE() 創建一個等待隊列的項，然後調用 add_wait_queue() 把自己加入到等待隊列中，並且將進程的狀態設置爲 TASK_INTERRUPTIBLE 或者 TASK_INTERRUPTIBLE。

然後循環檢查條件是否爲真：如果是的話就沒有必要睡眠，如果條件不爲真，就調用 schedule()。當進程檢查的條件滿足後，進程又將自己設置爲 TASK_RUNNING 並調用 remove_wait_queue() 將自己移出等待隊列。

從上面可以看到，Linux 的內核代碼維護者也是在進程檢查條件之前就設置進程的狀態爲睡眠狀態，然後才循環檢查條件。如果在進程開始睡眠之前條件就已經達成了，那麼循環會退出並用 set_current_state() 將自己的狀態設置爲就緒，這樣同樣保證了進程不會存在錯誤的進入睡眠的傾向，當然也就不會導致出現無效喚醒問題。

下面讓我們用 Linux 內核中的實例來看看其是如何避免無效睡眠的，這段代碼出自 Linux2.6 的內核 (/kernel/sched.c):

/* Wait for kthread_stop */
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop()) {
    schedule();
    set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
return 0;

上面的這些代碼屬於遷移服務線程 migration_thread，這個線程不斷地檢查 kthread_should_stop()，直到 kthread_should_stop() 返回 1 它纔可以退出循環，也就是說只要 kthread_should_stop() 返回 0 該進程就會一直睡眠。

從代碼中我們可以看出，檢查 kthread_should_stop() 確實是在進程的狀態被置爲 TASK_INTERRUPTIBLE 後纔開始執行的。因此，如果在條件檢查之後但是在 schedule() 之前有其他進程試圖喚醒它，那麼該進程的喚醒操作不會失效。

小結

通過上面的討論，可以發現在 Linux 中避免進程的無效喚醒的關鍵是在進程檢查條件之前就將進程的狀態置爲 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE，並且如果檢查的條件滿足的話就應該將其狀態重新設置爲 TASK_RUNNING。

這樣無論進程等待的條件是否滿足，進程都不會因爲被移出就緒隊列而錯誤地進入睡眠狀態，從而避免了無效喚醒問題。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8mRl4uJeamWLKW-7y9ZZHA

猜你喜歡