uC/OS-II Windows下虚拟的问题

时间:2018-07-25来源:网络

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

关键词: uC/OS-IIWindows 虚拟 问题

加入微信
获取电子行业最新资讯
搜索微信公众号:EEPW

或用微信扫描左侧二维码

相关文章

查看电脑版