uCOS-II中的任務切換-圖解多種任務調度時機與問題
|
【@.1 任務調度時機】 之前的一篇文章分析了具體的uCOS-II中的任務切換機制，是從函數調用的角度上分析的。這次我具體從整個程序運行的時間上來看，分析多種任務調度發生的時機。以下所有圖片均可點擊放大觀察。 所有圖中紅色箭頭表示中斷級的任務切換，藍色箭頭表示任務級的中斷切換。
1.僅有一個任務，這種情況最簡單。假設時鍾節拍是1000次每秒，由定時中斷產生，當節拍的時鍾服務程序結束時會調用OSInitExit，退出中斷，其中將進行上下文切換，運行當前就緒狀態優先級最高的任務，這里當然就是任務A、任務A中的代碼比較簡單，運行到最后時假設調用OSTimeDly(1)延時一個周期，提示系統放棄CPU控制權，這時將進行任務切換到空閑任務Idle Task。空閑任務優先級最低，是一個死循環，僅僅讓一個OSIdleCtr循環一次加一。可以看出，在一個時鍾節拍的間隔，這個計數器可能加不止一次。另外uCOS中還有一個統計任務，需配置打開，其中就是利用這個空閑計數器求出CPU有多少時間在空閑任務中，即有多少CPU占空比。通過圖示分析可以看出，很明顯雖然任務A延時一個時鍾周期，1ms，但是實際上將會少於1ms的延時。這就是為什么實際的延時中或多或少都會有延時抖動的現象，下面的很多例子的延時抖動都可能比這種情況更加復雜。
2.簡單的中斷，這里假設有一個外部中斷，在圖示處打斷了任務A的運行。外部中斷響應后進入服務函數，中斷退出時調用OSInitExit進行任務切換，回到剛才被中斷的任務。所以剛才的任務A就被延后了一段時間允許，之后任務A再切換到空閑任務。很明顯，這個時鍾周期內空閑計數器OSIdleCtr會少加一些，最后可以統計出CPU占用率會上升一些。
3.中斷函數中利用OSSemPost發送一個信號量，接受信號量的是任務B，其優先級大於任務A。於是在每次中斷服務函數結束時會首先調度任務B執行，按照圖中任務B的代碼只有一個OSSemPend可能會有等待掛起發送，之后任務B會因為等待接受信號量而調度會任務A繼續執行。圖中的畫出了三個外部中斷分別出現在不同時期，其中第三個外部中斷將導致任務B執行到一半遇到時鍾節拍的產生。這時候任務B會掛起，將執行節拍中斷服務程序，經過調度后會發現任務B任然處於就緒狀態，所以將繼續運行任務B直到結束。最后這里可以看出空閑任務在每個時鍾周期被擠得更少了，所以CPU的利用率更多。
4.跟第三中情況類似，只不過這里任務B中加了一句OSTimeDly(3)延時3個時鍾周期，這時可以知道，在任務B延時期間，只剩TaskA和空閑任務，他們將不會因為任務B的延時而被掛起。延時結束時，時鍾節拍將首先調度延時結束處於就緒狀態的任務B，之后再運行原本的任務A。這種情況也簡單的表示了uCOS是怎樣充分利用CPU資源的。
5.中斷中調用OSTaskResume恢復任務B。這里只是想說明，Resume/Suspend跟Post/Pend的區別，前者是一旦恢復則一直運行，而后者是Post一次，Pend方運行一次。
6.當用信號量通訊時，利用任務A來發送，控制高優先級的任務B接受信號量。可以看出，任務A發送一次信號量將會時任務B調度執行，此時任務A由於優先級低，被掛起，當任務B運行一次循環后又Pend等待信號量，這時任務B被掛起，由下一個時間周期的任務A發送，周而復始。 |
