當前位置: 妍妍網 > 碼農

Linux 行程的睡眠和喚醒

2024-02-24碼農

點選上方 Linux開源社群 」,選擇「 設為星標

優質文章,及時送達

轉自:網路

Linux行程的睡眠和喚醒

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

當然,一個行程也可以主動釋放CPU的控制權。函式 schedule() 是一個排程函式,它可以被一個行程主動呼叫,從而排程其它行程占用 CPU。一旦這個主動放棄 CPU 的行程被重新排程占用 CPU,那麽它將從上次停止執行的位置開始執行,也就是說它將從呼叫 schedule() 的下一行程式碼處開始執行。

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

Linux 中的行程睡眠狀態有兩種:

  • 一種是可中斷的睡眠狀態,其狀態標誌位TASK_INTERRUPTIBLE。

  • 另一種是不可中斷 的睡眠狀態,其狀態標誌位為TASK_UNINTERRUPTIBLE。

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

    在現代的 Linux 作業系統中,行程一般都是用呼叫 schedule() 的方法進入睡眠狀態的,下面的程式碼演示了如何讓正在執行的行程進入睡眠狀態。

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

    在第一個語句中,程式儲存了一份行程結構指標 sleeping_task current 是一個宏,它指向正在執行的行程結構。

    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);
    2if (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);
    3if (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);
    return0;

    上面的這些程式碼屬於遷移服務執行緒 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

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

    -End-

    讀到這裏說明你喜歡本公眾號的文章,歡迎 置頂(標星)本公眾號 Linux技術迷,這樣就可以第一時間獲取推播了~

    本公眾號,後台回復:Linux,領取2T學習資料 !

    1. 

    2. 

    3.

    4.