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开发者来说，选择合理的虚拟方式，对开发有巨大的影响。