實時操作系統(tǒng)的任務(wù)調(diào)度原因分析

在當(dāng)前的任務(wù)中，并沒有關(guān)于就緒表等全局變量的訪問，當(dāng)前的任務(wù)也有自己的堆?？臻g，我并不知道是否有更高優(yōu)先級的任務(wù)就緒，之所以產(chǎn)生這些疑惑是沒有搞清楚什么時候發(fā)生調(diào)度，怎么知道需要調(diào)度。當(dāng)前運行的任務(wù)，一般而言就是所謂的最高優(yōu)先級的任務(wù)，在沒有訪問一系列全局變量的過程中，內(nèi)核又是如何知道存在一個更高優(yōu)先級的任務(wù)被就緒了呢？

一般而言，對于搶占型實時內(nèi)核，一般在同步、或者通信的過程中會主動的調(diào)用調(diào)度函數(shù)，或者任務(wù)的掛起函數(shù)中使用調(diào)度函數(shù)，其他的函數(shù)中并沒有發(fā)現(xiàn)其他的調(diào)度函數(shù)，而且這種情況下都是手動的調(diào)度任務(wù)，那么在沒有這些函數(shù)的情況下，實時操作系統(tǒng)中內(nèi)核是如何知道需要調(diào)度的呢？

我仔細查找了一些資料，別人總結(jié)了一些操作系統(tǒng)發(fā)生調(diào)度的原因如下：
　　(1)正在執(zhí)行的進程執(zhí)行完畢。這時，如果不選擇新的就緒進程執(zhí)行，將浪費處理機資源。
　　(2)執(zhí)行中進程自己調(diào)用阻塞原語將白己阻塞起來進入睡眠等狀態(tài)。
　　(3)執(zhí)行中進程調(diào)用了P原語操作，從而因資源不足而被阻塞；或調(diào)用了v原語操作激活了等待資源的進程隊列。
　　(4)執(zhí)行中進程提出I/O請求后被阻塞。
　　(5)在分時系統(tǒng)中時間片已經(jīng)用完。
　　(6)在執(zhí)行完系統(tǒng)調(diào)用等系統(tǒng)程序后返回用戶進程時，這時可看作系統(tǒng)進程執(zhí)行完畢，從而可調(diào)度選擇一新的用戶進程執(zhí)行。
　　以上都是在可剝奪方式下的引起進程調(diào)度的原因。在CPU執(zhí)行方式是可剝奪時．還有
　　(7)就緒隊列中的某進程的優(yōu)先級變得高于當(dāng)前執(zhí)行進程的優(yōu)先級，從而也將引發(fā)進程調(diào)度。
我對比了在實時操作系統(tǒng)中經(jīng)常使用的調(diào)度方式發(fā)現(xiàn)，原因（2）、（3）、（7）是主要的原因，其他的一般在實時操作系統(tǒng)中很難找到。但是這還是不能回答什么時候發(fā)生調(diào)度這個問題。

我認(rèn)為在實時操作系統(tǒng)中發(fā)生調(diào)度的主要有兩個部分：
（1）自身需要睡眠等待，必須手動的調(diào)用調(diào)度函數(shù)（信息量，或者通信機制）。
（2）發(fā)生中斷過，當(dāng)執(zhí)行完中斷服務(wù)函數(shù)以后，需要重新調(diào)度。

其中原因（2）是我們在分析實時操作系統(tǒng)中實時性能的主要因素，很多人又會有很多的疑問，如果操作系統(tǒng)中很少使用中斷，實質(zhì)上在實時系統(tǒng)中必須存在的一個中斷就是時間節(jié)拍中斷，這個中斷的存在就能保證實時操作系統(tǒng)的實時型。這個時間節(jié)拍選擇也是設(shè)計過程中必須注意的。我們可以參看uC/OS-II的時間節(jié)拍代碼，其中完成了所有對非任務(wù)掛起的任務(wù)的就緒操作（時間到期），這時也就知道了那個任務(wù)需要我們調(diào)度。在其他的中斷服務(wù)函數(shù)執(zhí)行完成以后也就需要那個任務(wù)需要被執(zhí)行，進而實現(xiàn)了實時操作。

void OSTimeTick (void)
{
#if OS_CRITICAL_METHOD == 3 /* Allocate storage for CPUstatusregister */
OS_CPU_SR cpu_sr;
#endif
OS_TCB *ptcb;

OSTimeTickHook(); /* Call user definable hook */
#if OS_TIME_GET_SET_EN > 0
OS_ENTER_CRITICAL(); /* Update the 32-bit tick counter */
OSTime++;
OS_EXIT_CRITICAL();
#endif
if (OSRunning == TRUE) {
ptcb = OSTCBList; /* Point at first TCB in TCB list */
while (ptcb->OSTCBPrio != OS_IDLE_PRIO) { /* Go through all TCBs in TCB list */
OS_ENTER_CRITICAL();
if (ptcb->OSTCBDly != 0) { /* Delayed or waiting for event with TO */
if (--ptcb->OSTCBDly == 0) { /* Decrement nbr of ticks to end of delay */
if ((ptcb->OSTCBStat & OS_STAT_SUSPEND) == OS_STAT_RDY) { /* Is task suspended? */
OSRdyGrp |= ptcb->OSTCBBitY; /* No, Make task R-to-R (timed out)*/
OSRdyTbl[ptcb->OSTCBY] |= ptcb->OSTCBBitX;
} else {
/* Yes, Leave 1 tick to prevent ... */
ptcb->OSTCBDly = 1; /* ... loosing the task when the ... */
} /* ... suspension is removed. */
}
}
ptcb = ptcb->OSTCBNext; /* Point at next TCB in TCB list */
OS_EXIT_CRITICAL();
}
}
}

從上面的代碼中我們可以知道每個任務(wù)都會被掃描一次，檢測是否能夠就緒，如果能夠就緒就將就緒表中的值設(shè)置，這樣也就知道了是否有更高優(yōu)先級的任務(wù)就緒，是否需要調(diào)度操作。因為時間節(jié)拍中斷的不斷發(fā)生就能保證最高優(yōu)先級任務(wù)的發(fā)生。因此時間節(jié)拍中斷函數(shù)是在實時操作系統(tǒng)中非常重要的函數(shù)之一。當(dāng)然任務(wù)之間切換以及在中斷中切換到新的任務(wù)中的切換代碼也是非常重要的，但是這些一般涉及到CPU寄存器的值，需要匯編代碼實現(xiàn)。
因為中斷完成以后很多的任務(wù)可能因為信號量等信息的釋放已經(jīng)就緒，這時候必然需要任務(wù)的調(diào)度操作，這時候也就知道了那個任務(wù)是最高優(yōu)先級的，那個任務(wù)應(yīng)該被執(zhí)行。這時也就是發(fā)生調(diào)度的時刻。

在UC/OS-II中通常采用關(guān)閉中斷的方式進入臨界區(qū)，因為關(guān)閉了中斷，所有的中斷服務(wù)函數(shù)都不會被執(zhí)行，也就不會發(fā)生任務(wù)的調(diào)度。那么只有一個情況才會發(fā)生調(diào)度，也就是任務(wù)自身需要睡眠，手動選擇調(diào)度函數(shù)，但是在臨界區(qū)中不應(yīng)該發(fā)生睡眠等，因此也就不可能手動調(diào)度，因此所有發(fā)生調(diào)度的可能都被清除了，這樣也就保證了臨界區(qū)代碼的安全性。