uC/OS-II Windows下虛擬問題

(原創文章，轉載請註明出處，謝謝)

國內用uC/OS-II的人很多，最近uC/OS-III也開源了，實在是廣大RTOS愛好者之福。我也曾經用uC/OS-II開發過一些東西。當時是用uC/OS-II在windows平台上的類比。跑了一個“Hello World!!!”；大致感覺這種虛擬方式還不錯，能結合Visual C++這樣強悍的工具，或者Linux平台下的gdb這樣的工具，對uC/OS-II的代碼做單步跟蹤；深入的瞭解RTOS核心的執行過程。我覺得非常的好。然而在我深入瞭解了RTOS核心，瞭解了uC/OS-II在windows上的移植後，發現這種虛擬方式簡直是害人不淺……

那問題究竟在哪呢？首先 RTOS 區別於Windows、Linux、uCLinux這種系統，主要是其調度演算法不同。使用的是Rate Monotonic(RM 單調速率)調度演算法。這種演算法的最大特點是基於優先順序別的時間分配，如果有一個高優先順序別任務不放棄對CPU的佔有，那麼連作業系統的核心也得不到時間執行。Windows、Linux下是絕對不會出現這種情況的。即使一個任務佔了CPU 100%，使用者的操作只是反應慢了，還沒到什麼都動不了的程度。

那uC/OS-II在Windows平台上的移植，是怎麼做得呢？uC/OS-II的任務採用Windows的線程實現，使用OSTaskCreate即是建立一個Windows的線程，入口是使用者指定的任務。那們這裡就有一個問題，uC/OS-II更核心的OS_ENTER_CRITICAL和OS_EXIT_CRITICAL是怎麼實現的？利用Windows裡的二值訊號量實現的。這個二值訊號量只是用於進程內部的，但可以用於同一個進程內部的多個線程。那麼環境切換沒有什麼實際性的內容，只是調用Windows的API將高優先順序的任務恢複執行(對Windows來講是一個線程)，而低優先順序的任務掛起。上下文內容Windows會為RTOS儲存。

系統的時鐘節拍由Windows的多媒體時鐘提供，OSTickW32這個函數被當作一個獨立的線程運行。到時間了就執行一次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;
}

任務調度雖然按照Windows的調度演算法，但是通過定時執行核心代碼，基本上能保證RMS調度演算法的初衷。

雖然Windows下虛擬任務基本上滿足RMS調度的規則，然而仔細分析並不是那麼回事情。首先，所有的線程優先順序別對Windows來講是一樣的。不會因為uC/OS-II給他個高優先順序別，他就能得到更多的執行時間。如果uC/OS-II整個所在的虛擬進程在一個重負荷的環境下運行，不管什麼低優先順序高優先順序任務，得到的執行時間都是不確定的。
再次，uC/OS-II的任務基於Windows，全域臨界地區也是借用Windows的二值訊號量實現的。通常，我們用全域臨界地區可以鎖住uC/OS-II的調度器和中斷系統。然而，我們不要忘了，uC/OS-II的任務和調度器鎖住了，並沒有鎖住Windows的調度器。它還是可以完成線程切換的。絲毫不影響Windows的線程切換。由於windows 的線程切換受uC/OS-II的支配，還好，這種情況不會出什麼問題；但是反過來，如果禁止Windows的線程切換，並沒有通知uC/OS-II，那麼就完蛋了。uC/OS-II強制Windows切換到某一任務，造成整個系統死結(抱死)。

這種情況複雜：舉個例子，A任務是一個低優先順序別的任務，正在調用一個Windows的IO函數，此IO是臨界IO，剛剛進入這個IO的臨界地區，還沒出來。時間片到了，uC/OS-II強制Windows切換到處於就緒態的B任務，B任務優先順序別比A高。很不幸，B也想調用相同的IO函數，也要進入相同的臨界地區，那麼，我們來看，B線程得不到鎖，結果B死等A放鎖，這個是Windows層面的，對於uC/OS-II，它還認為B在執行。而 A任務因為B任務在執行，永久的等待，這個是uC/OS-II層面的，所以uC/OS-II也不會切換調度器讓B停止執行，讓A執行，以解開這個死結。即使該進程所有的線程都不執行了，對於Windows來說，也是允許的。對於uC/OS-II來說，它永遠的在執行B任務，而B任務在等一個他永遠也不可能得到的鎖。

調度由Windows核心完成，但IO操作還有一些實質性的操作都必須調用Windows的API完成，如果這些API潛在的影響了Windows的調度，而又沒有讓uC/OS_II知道，結果就是類比失敗。並且，這種情況要滿足特定的條件才能發生，現實中很不好調試，確定問題的位置。但解決的辦法也有，把所有Windows的API，任務中調用的API當作uC/OS-II的臨界地區，則不會發生死結。但這會產生巨大的類比開銷。

相對於這種寄生類比方式，skyeye、qemu等，更加的優越，更接近實際。雖然他們也有自己的問題，但至少，不會出現以上兩個問題。所以，對於RTOS開發人員來說，選擇合理的虛擬方式，對開發有巨大的影響。

(原創文章，轉載請註明出處，謝謝)