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