uC/OS-II Windows下虛擬的問題

國內(nèi)用uC/OS-II的人很多，最近uC/OS-III也開源了，實(shí)在是廣大RTOS愛好者之福。我也曾經(jīng)用uC/OS-II開發(fā)過一些東西。當(dāng)時(shí)是用uC/OS-II在windows平臺(tái)上的模擬。跑了一個(gè)“Hello World!!!”;大致感覺這種虛擬方式還不錯(cuò)，能結(jié)合Visual C++這樣強(qiáng)悍的工具，或者Linux平臺(tái)下的gdb這樣的工具，對(duì)uC/OS-II的代碼做單步跟蹤;深入的了解RTOS內(nèi)核的執(zhí)行過程。我覺得非常的好。然而在我深入了解了RTOS內(nèi)核，了解了uC/OS-II在windows上的移植后，發(fā)現(xiàn)這種虛擬方式簡直是害人不淺……

那問題究竟在哪呢?首先 RTOS 區(qū)別于Windows、Linux、uCLinux這種系統(tǒng)，主要是其調(diào)度算法不同。使用的是Rate Monotonic(RM 單調(diào)速率)調(diào)度算法。這種算法的最大特點(diǎn)是基于優(yōu)先級(jí)別的時(shí)間分配，如果有一個(gè)高優(yōu)先級(jí)別任務(wù)不放棄對(duì)CPU的占有，那么連操作系統(tǒng)的內(nèi)核也得不到時(shí)間執(zhí)行。Windows、Linux下是絕對(duì)不會(huì)出現(xiàn)這種情況的。即使一個(gè)任務(wù)占了CPU 100%，用戶的操作只是反應(yīng)慢了，還沒到什么都動(dòng)不了的程度。

那uC/OS-II在Windows平臺(tái)上的移植，是怎么做得呢?uC/OS-II的任務(wù)采用Windows的線程實(shí)現(xiàn)，使用OSTaskCreate即是創(chuàng)建一個(gè)Windows的線程，入口是用戶指定的任務(wù)。那們這里就有一個(gè)問題，uC/OS-II更核心的OS_ENTER_CRITICAL和OS_EXIT_CRITICAL是怎么實(shí)現(xiàn)的?利用Windows里的二值信號(hào)量實(shí)現(xiàn)的。這個(gè)二值信號(hào)量只是用于進(jìn)程內(nèi)部的，但可以用于同一個(gè)進(jìn)程內(nèi)部的多個(gè)線程。那么上下文切換沒有什么實(shí)際性的內(nèi)容，只是調(diào)用Windows的API將高優(yōu)先級(jí)的任務(wù)恢復(fù)執(zhí)行(對(duì)Windows來講是一個(gè)線程)，而低優(yōu)先級(jí)的任務(wù)掛起。上下文內(nèi)容Windows會(huì)為RTOS保存。

系統(tǒng)的時(shí)鐘節(jié)拍由Windows的多媒體時(shí)鐘提供，OSTickW32這個(gè)函數(shù)被當(dāng)作一個(gè)獨(dú)立的線程運(yùn)行。到時(shí)間了就執(zhí)行一次OSTickISR()。

DWORD WINAPI OSTickW32( LPVOID lpParameter )

{

OS_INIT_CRITICAL();

while(!OSTerminateTickW32)

{

OSTickISR();

#ifdef WIN_MM_TICK

if( WaitForSingleObject(OSTickEventHandle, 5000) == WAIT_TIMEOUT)

{

#ifdef OS_CPU_TRACE

OS_Printf(Error: MM OSTick Timeout!n);

#endif

}

ResetEvent(OSTickEventHandle);

#else

Sleep(1000/OS_TICKS_PER_SEC);

#endif

}

return 0;

}

任務(wù)調(diào)度雖然按照Windows的調(diào)度算法，但是通過定時(shí)執(zhí)行內(nèi)核代碼，基本上能保證RMS調(diào)度算法的初衷。

雖然Windows下虛擬的任務(wù)基本上滿足RMS調(diào)度的規(guī)則，然而仔細(xì)分析并不是那么回事情。首先，所有的線程優(yōu)先級(jí)別對(duì)Windows來講是一樣的。不會(huì)因?yàn)閡C/OS-II給他個(gè)高優(yōu)先級(jí)別，他就能得到更多的執(zhí)行時(shí)間。如果uC/OS-II整個(gè)所在的虛擬進(jìn)程在一個(gè)重負(fù)荷的環(huán)境下運(yùn)行，不管什么低優(yōu)先級(jí)高優(yōu)先級(jí)任務(wù)，得到的執(zhí)行時(shí)間都是不確定的。 再次，uC/OS-II的任務(wù)基于Windows，全局臨界區(qū)域也是借用Windows的二值信號(hào)量實(shí)現(xiàn)的。通常，我們用全局臨界區(qū)域可以鎖住uC/OS-II的調(diào)度器和中斷系統(tǒng)。然而，我們不要忘了，uC/OS-II的任務(wù)和調(diào)度器鎖住了，并沒有鎖住Windows的調(diào)度器。它還是可以完成線程切換的。絲毫不影響Windows的線程切換。由于windows 的線程切換受uC/OS-II的支配，還好，這種情況不會(huì)出什么問題;但是反過來，如果禁止Windows的線程切換，并沒有通知uC/OS-II，那么就完蛋了。uC/OS-II強(qiáng)制Windows切換到某一任務(wù)，造成整個(gè)系統(tǒng)死鎖(抱死)。

這種情況復(fù)雜：舉個(gè)例子，A任務(wù)是一個(gè)低優(yōu)先級(jí)別的任務(wù)，正在調(diào)用一個(gè)Windows的IO函數(shù)，此IO是臨界IO，剛剛進(jìn)入這個(gè)IO的臨界區(qū)域，還沒出來。時(shí)間片到了，uC/OS-II強(qiáng)制Windows切換到處于就緒態(tài)的B任務(wù)，B任務(wù)優(yōu)先級(jí)別比A高。很不幸，B也想調(diào)用相同的IO函數(shù)，也要進(jìn)入相同的臨界區(qū)域，那么，我們來看，B線程得不到鎖，結(jié)果B死等A放鎖，這個(gè)是Windows層面的，對(duì)于uC/OS-II，它還認(rèn)為B在執(zhí)行。而 A任務(wù)因?yàn)锽任務(wù)在執(zhí)行，永久的等待，這個(gè)是uC/OS-II層面的，所以u(píng)C/OS-II也不會(huì)切換調(diào)度器讓B停止執(zhí)行，讓A執(zhí)行，以解開這個(gè)死鎖。即使該進(jìn)程所有的線程都不執(zhí)行了，對(duì)于Windows來說，也是允許的。對(duì)于uC/OS-II來說，它永遠(yuǎn)的在執(zhí)行B任務(wù)，而B任務(wù)在等一個(gè)他永遠(yuǎn)也不可能得到的鎖。

調(diào)度由Windows核心完成，但I(xiàn)O操作還有一些實(shí)質(zhì)性的操作都必須調(diào)用Windows的API完成，如果這些API潛在的影響了Windows的調(diào)度，而又沒有讓uC/OS_II知道，結(jié)果就是模擬失敗。并且，這種情況要滿足特定的條件才能發(fā)生，現(xiàn)實(shí)中很不好調(diào)試，確定問題的位置。但解決的辦法也有，把所有Windows的API，任務(wù)中調(diào)用的API當(dāng)作uC/OS-II的臨界區(qū)域，則不會(huì)發(fā)生死鎖。但這會(huì)產(chǎn)生巨大的模擬開銷。

相對(duì)于這種寄生模擬方式，skyeye、qemu等，更加的優(yōu)越，更接近實(shí)際。雖然他們也有自己的問題，但至少，不會(huì)出現(xiàn)以上兩個(gè)問題。所以，對(duì)于RTOS開發(fā)者來說，選擇合理的虛擬方式，對(duì)開發(fā)有巨大的影響。