RTX实时操作系统教案资料.docx
《RTX实时操作系统教案资料.docx》由会员分享，可在线阅读，更多相关《RTX实时操作系统教案资料.docx（18页珍藏版）》请在冰豆网上搜索。
RTX实时操作系统教案资料
RTX-实时操作系统
使用RTX增加WindowsXP/2000/XPEmbedded系统的硬实时特性收藏
内容简介
摘要
简介
WindowsXP平台和实时系统
RTX结构
深入RTX
实时硬件抽象层
WindowsXP停止保护
扩展HAL
RTX和中断延迟
RTX中断延迟缩减技术
RTX对象
RTSS调度器
服务请求中断
Win32到RTSS的IPC
RTSS代理模型
控制WindowsXPI/O管理器
快速计时器支持
动态链接库
RTSS中的结构异常处理
性能
使用VisualStudio创建RTX应用程序
性能工具
目标设计者SLD
未来方向
结论
获取渠道
参考
摘要
由于很多商业和技术原因，Microsoft®WindowsNT®、MicrosoftWindows2000、WindowsXP和WindowsXPEmbedded操作系统越来越多被考虑作为实时系统平台。
为了满足硬实时系统严格的响应时间的要求，增加WindowsXP系统的实时能力非常必要。
这篇文章介绍了美国Ardence公司的RTX产品，其在Windows平台上提供了一个实时子系统。
RTX实现了确定性的实时线程调度、实时环境和与原始Windows环境之间的进程间通讯机制以及其它只在特定的实时操作系统中才有的对Windows系统的扩展特性。
这篇文章描述了RTX怎样提供这些特性和目前的实时性能，并指出了未来性能增强的方向。
简介
微软公司的WindowsXP操作系统的大众接受程度和市场占有率日益扩大。
这主要是基于以下几点原因：
•WindowsXP平台更强的性能和更低的价格；
•该平台上可运行多种应用程序；
•该平台支持多种开发工具；
•丰富的Win32应用程序接口；
•大量的熟悉本系统的开发支持人员和最终用户。
鉴于多系统的计算环境的复杂度和所需要的额外维护成本，更多的公司倾向于将WindowsXP应用到设备的所有级别上。
将其作为网络服务器或者桌面系统是很容易理解的，因为WindowsXP就是为这些环境而设计的。
但是，仍然有很多其他环境有使用WindowsXP的要求，譬如制造车间，医疗设备，仿真器械，测试设备和通信器材。
这些环境的共同特点就是它们都要求系统拥有硬实时特性。
WindowsXP可以满足这个需要吗？
答案是否定的。
但是，通过附加软件就可以在WindowsXP上实现所需要的硬实时特性。
否则的话，开发者必须增加一台实时计算机，并承担额外的费用和复杂度。
下文讨论了Ardence公司的硬实时产品RTX，其中包括RTSS实时子系统（Real-TimeSub-System），它是专门为PC架构（IntelPentium系列及其相应的操作系统）的Windows平台设计的。
此前的一篇文章[Carpenter97]讨论了开发过程中的一些成果，这篇文章提供了对实现的更详细的介绍，包括性能参数，功能的提高以及发展前景的概述。
WindowsXP平台和实时系统
什么样的系统可以被称为实时？
实时系统的特点在于：
一个正确的运行不仅取决于结果的准确，更取决于实现的时间。
需要注意的是，“实时”并不意味着“快”，它指的是系统的时间响应特性。
换句话说，实时性的衡量标准不是系统的平均响应时间而是最坏情况下的响应时间。
实时系统有时被进一步划分为硬实时系统和软实时系统。
硬实时系统对响应时间的要求是严格的，绝对的；而软实时系统允许有一些小的误差。
某些观点认为“软实时”的说法是自相矛盾的，在下文中凡涉及到“实时”都指的是硬实时系统。
一个硬实时系统的例子是压盖机给在传送带上传送的瓶子加盖。
对于系统，仅仅准确定位压盖机是不够的，如果瓶盖已经移走而压盖机才刚刚到位那么所有的精确定位都是徒劳的。
除了确定性，实时系统通常还有一些其他要求：
•一个具有很多优先级的多线程优先级调度器（如典型的64-256）；
•可预测的线程同步机制；
•具有优先级继承
•快速的时钟和定时器
为什么WindowsXP平台不是实时的？
WindowsXP是一个通用操作系统平台，同时适合于桌面交互系统和网络服务器[Solomon98]。
WindowsXP（同时适用于WindowsXPEmbedded）在实时应用方面的缺点已经被很系统地研究过了：
•线程优先级太少；
•隐含的不确定的线程调度机制；
•优先级倒置，尤其体现在中断处理中；
尽管更快的处理器显著的增加了处理能力和平均响应时间，甚至使某些人以为实现系统的实时性变为可能，但是非确定性系统是不能变成确定系统的，最坏响应时间的提高也不是总能被保证的。
所以，新的硬件平台并不能改变WindowsXP的实时特性。
某些开发人员使用了两台计算机----一台运行WindowsXP，另一台运行实时系统。
但是这增加了大量的硬件成本并使系统的开发和集成变得复杂，不是一种通用的、高效率的解决方案。
为什么要对WindowsXP平台进行实时扩展？
RTX的设计逻辑基于以下几个因素。
通用的WindowsXP操作系统是面向大众市场的，不适合实时性这样非普遍的需求。
尽管由微软赞助的关于WindowsXP实时性的研究已经有了一些进展[Sommer96]----尤其当应用程序事先声明其资源需要的时候[Sommer97][Sommer&Potter96]----但对于WindowsXP这种面向广阔市场的操作系统，吸收实时性系统的复杂性以完成其功能，其可行性是值得怀疑的[Microsoft95]。
这意味着使WindowsXP具有实时性的最好方法是通过对原产品的扩展或者由插件实现[Jones98]。
同时，WindowsXP平台提供了丰富的和复杂的设备驱动模型，定制的硬件抽象层（hardwareabstractionlayer，HAL）和模型为开发者提供了对系统行为的灵活掌控能力和面对技术挑战的创造性机会。
这样，实时功能可以按照微软WindowsXP驱动开发工具（DriverDevelopmentKit，DDK）和HAL模型来实现[Baker97]。
最后，对于非微软员工的WindowsXP扩展内核编写人员，WindowsXP的内核就如同硅制芯片一样，其接口和行为都是固定的。
无需抱怨，利用现有的条件就可以设计出紧凑的实时性扩展，使其易于在不同的Windows版本之间进行移植。
图1说明了RTX如何实现可移植性的目标。
那么，你需要一个硬实时的WindowsXP环境吗？
为何将WindowsXP扩展为实时系统？
既然刚才提到的微软WindowsXP平台的许多缺点都是由于其线程模型和线程调度，那么实时扩展拥有自己的线程和调度也就十分必要了。
同样，WindowsXP平台的同步对象，例如事件，信号量，互斥体等缺乏必要的实时机制（尤其它们既无法防止线程侵占，又无法使线程按优先级顺序等待对象响应）。
由于这些原因，实时扩展应该实现自己的同步对象[Bollella95]。
如果按照WindowsXP的环境逻辑实现一个实时子系统，这个实时环境应该能够：
•无论在任何时间其优先级都应该高于WindowsXP，至少在WindowsXP中断处理程序代码的临界区以外。
•执行实时任务时，延迟WindowsXP的中断和错误。
•实行实时任务时，要能够处理实时中断。
抢占WindowsXP和其驱动的高级别中断请求（InterruptRequestNumber，IRQ）让给没有时间约束的实时任务是一种危险的想法。
但是这些事件是常见的，并且WindowsXP被设计用来处理它们：
高优先级中断请求（high-interruptrequestlevel，IRQL）侵占低级的；DMA外设的总线控制和系统管理模式下的处理可以延迟最高级别的中断请求；PCI设备可以拖延CPU对I/O空间的访问。
所以，从WindowsXP的观点来看，RTSS窃取WindowsXP的执行周期就等同于获得中断并返回。
这样的时间能被WindowsXP很好的处理，而不必考虑其持续时间。
实时子系统的功能需要包括与Win32子系统的进程间通讯（interprocesscommunication，IPC），访问WindowsXP内核功能（中断管理，I/O端口，关机/崩溃处理器），最重要的是与Win32在源代码级别上兼容。
RTX结构
RTX被实现为一套库的集合（动态库与静态库），RTSS作为WindowsXP的内核设备驱动与HAL扩展（见图1）[Carpenter97]。
子系统实现前面提到的实时对象和调度器。
通过一套被称作RtWinAPI的实时API（RtWinAPI同时也被WindowsCE和PharLapETS支持）这套库提供了对这些对象的访问方法。
注意，RtWinAPI可以被标准Win32环境和RTSS环境调用。
虽然在Win32环境中使用RtWinAPI不能提供在RTSS下的确定性，但是却可以允许应用程序在更加友好的Win32编程环境中开发而不是DDK环境[Anschuetz98]。
将Win32程序转化为RTX程序只需要重新链接一套不同的库而已。
WindowsXP服务控制管理器直接将RTX进程和动态链接库（DLL）的可执行映像装入内核的不分页内存中。
图1RTX架构
深入RTX
实时硬件抽象层（HAL）
HAL是WindowsXP系统提供的可被用来进行修改和扩展的资源的一部分。
RTX修改HAL有以下3个目的：
•在WindowsXP和RTX线程之间增加独立的中断间隔；
•实现高速时钟和定时器；
•实现关闭处理程序。
中断隔离意味着WindowsXP线程和WindowsXP管理的设备不可能中断RTSS，同时WindowsXP线程也不能屏蔽RTSS管理的设备。
HAL通过控制处理器级的中断屏蔽满足这些条件。
当运行RTSS线程时，所有WindowsXP控制的中断都被屏蔽掉。
当WindowsXP线程请求设置中断屏蔽时，作为实际管理中断屏蔽的软件，HAL确保没有任何RTSS中断被屏蔽。
WindowsXP提供的计时器的最小计时单位为1000微秒（1毫秒）。
RT-HAL将其降到了100纳秒并且提供了同步（与计时器）的时钟。
WindowsXP停止保护
除了中断管理和更快的定时器服务，实时HAL也提供了WindowsXP关机管理。
当WindowsXP正常关机或者蓝屏崩溃时，RTSS应用程序可以被关联到WindowsXP关机管理器。
正常关机允许RTSS不受影响的继续运行，直到所有的RTSS关机处理器返回。
但当出现蓝屏时，RTSS关机处理器就会受到限制，它将无法调用WindowsXP的服务（例如分配新内存）。
在实际中，这意味着当系统正常关机或者崩溃时，关机处理器清除一切并复位硬件，还可能向操作者发出警告，或者切换到备用状态。
图2：
RTSS详细架构
扩展HAL
自从RTX4.3，一直采用扩展HAL的方式而不是替代。
HAL扩展驱动在操作系统初始化时启动（SERVICE_SYSTEM_START），在内存中完成对HAL的动态检测、中断截取、定时器和关机的相关调用，并且重定向到RTX的相应位置。
这种二进制钩子技术比起替代HAL来有许多优点：
•RTX可以处理很广泛的OEM平台，这种重定向调用被限制在一种对于不同的OEM和服务商之间很少区别的调用上。
•RTX兼容更大范围的WindowsXP补丁包（ServicePack，SP），为了配合最新的HAL资源的补丁包而修改RTX是不必要的。
•因为磁盘上的HAL未被改动，所以安装变得更加容易，因此RTX也不受SP升级的影响。
•升级到更新的Windows版本变得容易，不费什么力气。
当RTX在WindowsNT和Windows2000的后续SP上不经修改的成功安装，扩展HAL的好处也就无需证明了。
RTX和中断延迟
软件引起的中断
当RTX高速时钟或者其他设备产生RTX中断时，就会发生从WindowsXP到RTX的转换。
所以，为达到RTX的ISR的确定性就必须减少WindowsXP的中断延迟。
让我们先来考察一下在没有RTX的情况下WindowsXP平台的ISR延迟来源。
最显著的延迟是由WindowsXP内核和驱动引起的IRQ屏蔽，一般是通过WindowsXP的KeRaise/LowerIrql函数调用在几毫秒内实现的。
WindowsXP内核，HAL和某些特殊驱动也通过x86STI/CLI指令集在几微秒内完成处理器级的中断屏蔽。
WindowsXP和RTX中断处理自然会屏蔽中断，所以也肯定会增加ISR延迟。
虽然在很多情况下WindowsXP非常依赖于中断处理（例如软件异常，释放线程堆栈），但其中断顺序依然取决于最坏情况下的延时。
硬件引起的中断
和硬件有关的最明显的问题就是应用程序和操作系统对高速缓存的污染和转储清除。
TLB的重填也属于这种情况。
视频驱动的缓存占有量是极大的，当RTX中断启动时会造成竞争性的转储清除。
当应用程序引起缓存污染时，ISR的直方图上将出现典型的双驼峰型。
大部分采样靠近最好情况的区域，另外一大部分靠近存储清除的区域（见图3）。
电源管理，尤其是当其在移动设备上，当CPU经过较长时间的停滞而处于低耗电量状态时偶尔会产生较长的延迟。
这种问题很容易被侦查到。
一个典型的系统可以通过BIOS的设置来禁止这些特性。
某些系统，尤其是笔记本，使用Pentium处理器的系统管理模式（SystemManagementMode，SMM）在BIOS固化软件中完成敲击键盘和其他处理。
同时，在SMM下，处理器不会处理增加ISR延迟的中断。
幸运的是，新一代系统平台通过高级设置与电源接口（AdvancedConfigurationandPowerInterface，ACPI）和Windows2000转而使用操作系统而不是BIOS提供电源管理。
因此，这些延迟的原因已经变得微不足道了。
总线控制事件会引起CPU长时间的延迟。
这种情况包括小型电脑系统接口（smallcomputersysteminterface，SCSI）设备的高性能DMA所引起的数微秒的CPU延迟和为响应CPU访问而加入等待周期的显卡。
有时这些外设的行为可以被驱动控制，通过交替处理从而减少延迟。
虽然没有任何系统能够确保应用程序不受这些硬件因素的干扰，但是RTX提供了诊断平台相关延迟的诊断工具，可以辨别那些行为错误的外设。
留意这些因素并使用RTX工具来衡量开发平台对于一个系统的整体性能来说是非常重要的。
RTX中断延迟缩减技术
RTSS完全消除了由WindowsXP平台及其驱动的IRQL屏蔽所造成的延迟。
当系统在WindowsXP与RTX之间进行切换时，RT-HAL执行中断隔离，重新对可编程中断控制器（programmableinterruptcontroller，PIC）进行编程。
所以在RTX运行时，RTX可以屏蔽所有WindowsXP中断，从而RTX中断总能够屏蔽WindowsXP。
另一方面，处理器级的中断屏蔽不会失效，因此不必冒风险使用x86NMIs（不可屏蔽中断，non-maskableinterrupts）。
RTX采用一种静态方案解决IRQ锁定，它将多个中断优先级挂钩，这种动态挂钩功能使用旋转锁定（或者在单处理器上的基于IRQ的同步）扫描HAL，寻找这些操作的信号。
在典型的800MHZ的PC平台上，这些技术提供了小于1微秒的时钟中断最坏延迟响应时间。
RTX对象
RTSS环境拥有快捷高效的对象管理器（见图2）。
它支持的对象满足下列标准：
1）可用于实时编程
2）兼容Win32
IPC对象同样适用于Win32应用程序和设备驱动，允许程序员最大限度的发挥WindowsXP的性能。
IPC设置包括互斥体，事件，信号量和共享内存对象。
RTSS对象管理器使用WindowsXP的不分页内存池以满足它的存储需要。
使用WindowsXP提供的机制可以减少RTX的资源消耗，但是对象的分配是不确定的。
RTSS调度器
RTSS调度器采用抢占式策略实现优先级，它可以提升优先级以防止优先级倒置。
RTSS环境提供了128种优先级，序号从0到127，0代表最低优先权。
RTSS调度器总是在准备运行的线程中运行优先级最高的（当多个准备运行的线程处于同一优先级时，等待时间最长的线程最先运行）。
RTSS线程会一直运行直到一个高优先级的就绪线程抢占它，或者它自动释放处理器进入等待状态，还有一种情况是分配给它的时间片用光（缺省值是无限）而另一个同优先级线程已经就绪。
调度器在编码设计阶段就被设计为满足实时处理的需要。
最重要的是它的操作是低延迟的，并且不受它所管理的线程数影响。
每个优先级都有自己的等待队列，是一个双向链表。
这就使得对于链表的插入（表尾）和删除（表的任何位置）操作的执行时间独立于链表中的线程数。
一个数组会纪录哪些链表当前是空的，这个数组是由高速的由汇编代码写成的子程序进行维护的。
当一个RTSS线程运行时，所有WindowsXP管理的中断以及任何拥有低优先级的线程所管理的中断都一律被屏蔽掉。
相反地，所有拥有高优先级的线程所管理的中断都不会被屏蔽，并且允许其打断当前线程。
除了这些设备中断，其他可以导致当前线程被中断的机制包括一个使得拥有高优先级的线程就绪的定时器的到期，一个标明高优先级线程正在等待的同步对象信号（正在运行线程的同步对象）。
为了解决线程抢占的问题，RTSS采用了经典的优先级提升的解决方案[Nakajima93][Sha90]。
当一个低优先级线程拥有一个高优先级线程等待的对象时，在它拥有对象的时间内会被自动提升到较高的优先级别。
服务请求中断（ServiceRequestInterrupt，SRI）
RTX的一个重要的架构特征就是WindowsXP和RTX之间的一个无锁中断驱动接口，这个接口实现了本地程序调用（LocalProcedureCall，LPC）机制。
这个完全分离的架构使得RTSS能够移植到不同的环境中（例如多处理器RTX产品），并能够保证快速而有效的实现。
WindowsXP方面的RTX驱动和RTSS环境之间的通讯是通过向两个缓存队列（每个方向一个队列）中的一个插入命令行，并初始化服务请求中断（ServiceRequestInterrupt，SRI）来向另一方请求服务的。
一个服务线程执行请求，其应答信息的传递通过另一个队列。
典型的WindowsXP到RTX的请求是一个与WaitForSingleObject相似的IPC操作或者在RTSS对象上的释放操作。
而典型的RTX到WindowsXP的操作是页内存的分配或者I/O请求。
SRI的设计倾向于减少响应时间，尽快地响应RTSS请求。
Win32到RTSS的IPC
交互环境下的IPC是RTX的一个重要特征，它允许在运行实时程序的资源更加密集的RTSS环境下紧密的集成应用程序。
应用程序的其余部分运行在Win32子系统中，这一节描述了IPC的设计。
RTSS代理模型
IPC与其它WindowsXP和RTSS之间的通信相同，使用SRI通道。
由于SRI通道阻止WindowsXP线程进入队列直接获得RTX对象，RTX使用代理进程和线程支持IPC与Win32的隔离。
当Win32线程要访问到RTX对象时，RTSS就会使用代理线程，这个模型简捷有效，它的优点如下：
•在阻塞IPC请求时，在WindowsXP端没有状态保留。
•对于外部的Win32等待请求，RTSS没有特例
•当Win32进程或线程终止后句柄和对象的清理工作自动由RTX的代理进程和线程完成。
虽然代理会涉及到内存和CPU的一些额外开销，但其简洁的设计和快速的实现使得这样做还是值得的。
控制WindowsXPI/O管理器
为交互环境IPC保留无缝的Win32语义并且达到好的性能面临几大挑战。
当使用某个驱动的Win32线程终止时，WindowsNT4.0DDK并不为驱动线程提供暴露的接口（Windows2000和WindowsXP引入了全局声明机制，但还存在一定的局限）。
但Win32的互斥体需要这样的机制。
当某个线程终止时，被其获得而不是释放了的RTX互斥体必须被标注为“废弃的”，以表明它所保护的共享数据可能并不一致。
RTX利用I/O管理器的I/O请求包（IRP，I/ORequestPacket）实现线程终止时的清除工作：
每个关联到RTXWin32DLL的线程向RTX驱动发送一个“死IRP”信号。
当这个线程终止时，WindowsXP调用IRP的取消子程序通知RTX驱动和RTSS对象层。
I/O管理器提了一个强大的，富有挑战的环境，因为它的事件传送是异步的。
例如，调用MJ_CLEANUP驱动调度子程序和取消子程序可以按照任何顺序，只要RTX的每个线程结构和每个进程保持严格的同步。
Win32-RTSSIPC的性能提出了另一个问题。
在早期的执行过程中，一个无须争议的事实是对Win32中的RtWaitForSingleObject（）函数的调用的总延迟平均为130毫秒，分析表明，大约40毫秒（大于30%）被消耗在WindowsXP的I/O管理器上。
所以RTX4.2对IPC内核进行了重新编码，在Win32IPC客户和RTX驱动之间使用了直接信号和共享内存[Tomlinson97]。
RTX用户和内核线程共享同步对象，直接与对方进行通信，这样就减少了WindowsXPI/O管理器的总开销和总延迟。
需要注意的是，被Win32应用程序锁住的在RTX同步对象上的操作具有不确定性[Carpenter97]：
任何RTSS线程都可以抢占WindowsXP中具有这种具有锁性质的线程，从而出现非常严重的优先级倒置的现象。
但这是程序设计上的问题：
锁定一个被Win32共享的对象应该留给一个非临界的RTSS线程去做。
不过在多处理器RTX系统上，并且如果RTX和WindowsXP分别运行于不同的处理器的话，这个问题可以得到改善。
快速计时器支持
在所有的PC平台上，实时的HAL提供了精度为1微秒甚至更快的时钟。
如果没有任何RTSS应用程序在执行，那么在安装了RTX的系统上和没有安装RTX的系统上就没有任何时间上的区别了。
动态链接库
提到Win32就不得不提到DLL库。
RTSS支持Win32DLLAPI（LoadLibrary函数，GetProcAddress函数）。
现在，所有在RTSS的DLL中的静态和全局变量都被链
升级会员 