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

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

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

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

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

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();
}
}
}

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

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