RTX技术文章V1.3.doc

RTX
Real-Time Extension for Control of Windows

技术白皮书

美国Ardence公司
北京美斯比科技有限公司

摘要

随着实时嵌入式技术的发展，Windows系列操作系统越来越多的被考虑作为实时系统的应用平台。为了满足硬实时系统严格的响应时间要求，增加Windows系统的实时能力非常必要。这篇文章介绍了美国Ardence公司的RTX产品，RTX在Windows平台上提供了一个实时子系统，实现了确定性的实时线程调度、实时环境和与原始Windows环境之间的进程间通讯机制以及其它只在特定的实时操作系统中才有的对Windows系统的扩展特性。这篇文章描述了RTX怎样提供这些特性和目前的实时性能，并指出了未来性能增强的方向。

目录
简介
Windows 平台和实时系统
RTX结构
深入RTX
实时硬件抽象层
Windows 停止保护
扩展HAL
RTX和中断延迟
RTX中断延迟缩减技术
RTX对象
RTSS调度器
服务请求中断
Win32到RTSS的IPC
RTSS代理模型
控制Windows I/O管理器
快速计时器支持
动态链接库
RTSS中的结构异常处理
性能
使用Visual Studio创建RTX应用程序
性能工具
目标设计者SLD
未来方向
结论
获取渠道
参考

简介
微软公司的Windows 系列操作系统的大众接受程度和市场占有率日益扩大。这主要是基于以下几点原因：
· Windows 平台更强的性能和更低的价格；
· 该平台上可运行多种应用程序；
· 该平台支持多种开发工具；
· 丰富的Win32应用程序接口；
· 大量的熟悉本系统的开发支持人员和最终用户。
鉴于多系统的计算环境的复杂度和所需要的额外维护成本，更多的公司倾向于将Windows应用到设备的所有级别上。将其作为网络服务器或者桌面系统是很容易理解的，因为Windows就是为这些环境而设计的。但是，仍然有很多其他环境有使用Windows的要求，譬如制造车间，医疗设备，仿真器械，测试设备和通信器材。这些环境的共同特点就是它们都要求系统拥有硬实时特性。
Windows可以满足这个需要吗？答案是否定的。但是，通过附加软件就可以在Windows上实现所需要的硬实时特性。否则的话，开发者必须增加一台实时计算机，并承担额外的费用和复杂度。下文讨论了Ardence公司的硬实时产品RTX，其中包括RTSS实时子系统（Real-Time Sub-System），它是专门为PC架构的Windows平台设计的。
此前的一篇文章[Carpenter 97]讨论了开发过程中的一些成果，这篇文章提供了对实现的更详细的介绍，包括性能参数，功能的提高以及发展前景的概述。

Windows 平台和实时系统

什么样的系统可以被称为实时？
实时系统的特点在于：一个正确的运行不仅取决于结果的准确，更取决于实现的时间。需要注意的是，“实时”并不意味着“快”，它指的是系统的时间响应特性。换句话说，实时性的衡量标准不是系统的平均响应时间而是最坏情况下的响应时间。实时系统有时被进一步划分为硬实时系统和软实时系统。硬实时系统对响应时间的要求是严格的，绝对的；而软实时系统允许有一些小的误差。某些观点认为“软实时”的说法是自相矛盾的，在下文中凡涉及到“实时”都指的是硬实时系统。
一个硬实时系统的例子是压盖机给在传送带上传送的瓶子加盖。对于系统，仅仅准确定位压盖机是不够的，如果瓶盖已经移走而压盖机才刚刚到位那么所有的精确定位都是徒劳的。
除了确定性，实时系统通常还有一些其他要求：
· 一个具有很多优先级的多线程优先级调度器；
· 可预测的线程同步机制；
· 具有优先级继承
· 快速的时钟和定时器

为什么Windows平台不是实时的？
Windows是一个通用操作系统平台，同时适合于桌面交互系统和网络服务器[Solomon 98]。Windows在实时应用方面的缺点已经被很系统地研究过了：
· 线程优先级太少；
· 隐含的不确定的线程调度机制；
· 优先级倒置，尤其体现在中断处理中；
尽管更快的处理器显著的增加了处理能力和平均响应时间，甚至使某些人以为实现系统的实时性变为可能，但是非确定性系统是不能变成确定系统的，最坏响应时间的提高也不是总能被保证的。所以，新的硬件平台并不能改变Windows 的实时特性。
某些开发人员使用了两台计算机----一台运行Windows，另一台运行实时系统。但是这增加了大量的硬件成本并使系统的开发和集成变得复杂，不是一种通用的、高效率的解决方案。

为什么要对Windows 平台进行实时扩展？
RTX的设计逻辑基于以下几个因素。通用的Windows 操作系统是面向大众市场的，不适合实时性这样非普遍的需求。尽管由微软赞助的关于Windows实时性的研究已经有了一些进展[Sommer 96]----尤其当应用程序事先声明其资源需要的时候[Sommer 97][Sommer & Potter 96] ----但对于Windows 这种面向广阔市场的操作系统，吸收实时性系统的复杂性以完成其功能，其可行性是值得怀疑的[Microsoft 95]。这意味着使Windows 具有实时性的最好方法是通过对原产品的扩展或者由插件实现[Jones 98]。
同时，Windows 平台提供了丰富的和复杂的设备驱动模型，定制的硬件抽象层(hardware abstraction layer ，HAL)和模型为开发者提供了对系统行为的灵活掌控能力和面对技术挑战的创造性机会。这样，实时功能可以按照微软Windows 驱动开发工具(Driver Development Kit，DDK)和HAL模型来实现[Baker 97]。
最后，对于非微软员工的Windows 扩展内核编写人员，Windows 的内核就如同硅制芯片一样，其接口和行为都是固定的。无需抱怨，利用现有的条件就可以设计出紧凑的实时性扩展，使其易于在不同的Windows版本之间进行移植。图1说明了RTX如何实现可移植性的目标。

图1 RTX架构
那么，你需要一个硬实时的Windows环境吗？

为何将Windows 扩展为实时系统？
既然刚才提到的微软Windows 平台的许多缺点都是由于其线程模型和线程调度，那么实时扩展拥有自己的线程和调度也就十分必要了。同样，Windows 平台的同步对象，例如事件，信号量，互斥体等缺乏必要的实时机制(尤其它们既无法防止线程侵占，又无法使线程按优先级顺序等待对象响应)。由于这些原因，实时扩展应该实现自己的同步对象[Bollella 95]。
如果按照Windows 的环境逻辑实现一个实时子系统，这个实时环境应该能够：
· 无论在任何时间其优先级都应该高于Windows，至少在Windows中断处理程序代码的临界区以外。
· 执行实时任务时，延迟Windows的中断和错误。
· 实行实时任务时，要能够处理实时中断。
抢占Windows 和其驱动的高级别中断请求(Interrupt Request Number，IRQ)让给没有时间约束的实时任务是一种危险的想法。但是这些事件是常见的，并且Windows被设计用来处理它们：高优先级中断请求(high-interrupt request level，IRQL)侵占低级的；DMA外设的总线控制和系统管理模式下的处理可以延迟最高级别的中断请求；PCI设备可以拖延CPU对I/O空间的访问。所以，从Windows 的观点来看，RTSS窃取Windows的执行周期就等同于获得中断并返回。这样的时间能被Windows很好的处理，而不必考虑其持续时间。
实时子系统的功能需要包括与Win32子系统的进程间通讯(interprocess communication，IPC)，访问Windows内核功能(中断管理，I/O端口，关机/崩溃处理器)，最重要的是与Win32在源代码级别上兼容。

RTX结构
RTX被实现为一套库的集合(动态库与静态库)，RTSS作为Windows的内核设备驱动与HAL扩展(见图1)[Carpenter 97]。子系统实现前面提到的实时对象和调度器。通过一套被称作RtWinAPI的实时API(RtWinAPI 同时也被Windows CE 和Phar Lap ETS支持)这套库提供了对这些对象的访问方法。注意，RtWinAPI可以被标准Win32环境和RTSS环境调用。虽然在Win32环境中使用RtWinAPI不能提供在RTSS下的确定性，但是却可以允许应用程序在更加友好的Win32编程环境中开发而不是DDK环境[Anschuetz 98]。将Win32程序转化为RTX程序只需要重新链接一套不同的库而已。Windows服务控制管理器直接将RTX进程和动态链接库(DLL)的可执行映像装入内核的不分页内存中。

深入RTX

实时硬件抽象层(HAL)
HAL是Windows 系统提供的可被用来进行修改和扩展的资源的一部分。RTX修改HAL有以下3个目的：
· 在Windows 和RTX线程之间增加独立的中断间隔；
· 实现高速时钟和定时器；
· 实现关闭处理程序。
中断隔离意味着Windows线程和Windows管理的设备不可能中断RTSS，同时Windows 线程也不能屏蔽RTSS管理的设备。HAL通过控制处理器级的中断屏蔽满足这些条件。当运行RTSS线程时，所有Windows控制的中断都被屏蔽掉。当Windows线程请求设置中断屏蔽时，作为实际管理中断屏蔽的软件，HAL确保没有任何RTSS中断被屏蔽。
Windows提供的计时器的定时周期为1000微秒(1毫秒)。RT-HAL将其降到了100微秒并且提供了同步(与计时器)的时钟，其最小分辨率为100纳秒。

Windows 停止保护
除了中断管理和更快的定时器服务，实时HAL也提供了Windows关机管理。当Windows正常关机或者蓝屏崩溃时， RTSS应用程序可以被关联到Windows 关机管理器。正常关机允许RTSS不受影响的继续运行，直到所有的RTSS关机处理器返回。但当出现蓝屏时，RTSS关机处理器就会受到限制，它将无法调用Windows的服务(例如分配新内存)。在实际中，这意味着当系统正常关机或者崩溃时，关机处理器清除一切并复位硬件，还可能向操作者发出警告，或者切换到备用状态。

扩展HAL
自从RTX4.3，一直采用扩展HAL的方式而不是替代。HAL扩展驱动在操作系统初始化时启动(SERVICE_SYSTEM_START)，在内存中完成对HAL的动态检测、中断截取、定时器和关机的相关调用，并且重定向到RTX的相应位置。这种二进制钩子技术比起替代HAL来有许多优点：
· RTX可以处理很广泛的OEM平台，这种重定向调用被限制在一种对于不同的OEM和服务商之间很少区别的调用上。
· RTX兼容更大范围的Windows补丁包(Service Pack，SP)，为了配合最新的HAL资源的补丁包而修改RTX是不必要的。
· 因为磁盘上的HAL未被改动，所以安装变得更加容易，因此RTX也不受SP升级的影响。
· 升级到更新的Windows版本变得容易，不费什么力气。
当RTX在Windows 2000和XP的后续SP上不经修改的成功安装，扩展HAL的好处也就无需证明了。

RTX和中断延迟

软件引起的中断
当RTX高速时钟或者其他设备产生RTX中断时，就会发生从 Windows到RTX的转换。所以，为达到RTX的ISR的确定性就必须减少Windows的中断延迟。让我们先来考察一下在没有RTX的情况下Windows平台的ISR延迟来源。
最显著的延迟是由Windows内核和驱动引起的IRQ屏蔽，一般是通过Windows的KeRaise/LowerIrql函数调用在几毫秒内实现的。Windows内核，HAL和某些特殊驱动也通过x86 STI/CLI指令集在几微秒内完成处理器级的中断屏蔽。
Windows 和RTX中断处理自动会屏蔽中断，所以也肯定会增加ISR延迟。虽然在很多情况下Windows非常依赖于中断处理(例如软件异常，释放线程堆栈)，但其中断顺序依然取决于最坏情况下的延时。

硬件引起的中断
和硬件有关的最明显的问题就是应用程序和操作系统对高速缓存的污染和转储清除。TLB的重填也属于这种情况。视频驱动的缓存占有量是极大的，当RTX中断启动时会造成竞争性的转储清除。当应用程序引起缓存污染时，ISR的直方图上将出现典型的双驼峰型。大部分采样靠近最好情况的区域，另外一大部分靠近存储清除的区域(见图2)。
电源管理，尤其是当其在移动设备上，当CPU经过较长时间的停滞而处于低耗电量状态时偶尔会产生较长的延迟。这种问题很容易被侦查到。一个典型的系统可以通过BIOS的设置来禁止这些特性。
某些系统，尤其是笔记本，使用Pentium处理器的系统管理模式(System Management Mode，SMM)在BIOS固化软件中完成敲击键盘和其他处理。同时，在SMM下，处理器不会处理增加ISR延迟的中断。
幸运的是，新一代系统平台通过高级设置与电源接口(Advanced Configuration and Power InterfaceACPI)和Windows 2000转而使用操作系统而不是BIOS提供电源管理。因此，这些延迟的原因已经变得微不足道了。
总线控制事件会引起CPU长时间的延迟。这种情况包括小型电脑系统接口(small computer system interface ，SCSI)设备的高性能DMA所引起的数微秒的CPU延迟和为响应CPU访问而加入等待周期的显卡。有时这些外设的行为可以被驱动控制，通过交替处理从而减少延迟。
虽然没有任何系统能够确保应用程序不受这些硬件因素的干扰，但是RTX提供了诊断平台相关延迟的诊断工具，可以辨别那些行为错误的外设。留意这些因素并使用RTX工具来衡量开发平台对于一个系统的整体性能来说是非常重要的。

RTX中断延迟缩减技术
RTSS 完全消除了由Windows平台及其驱动的IRQL屏蔽所造成的延迟。当系统在Windows与RTX之间进行切换时，RT-HAL执行中断隔离，重新对可编程中断控制器(programmable interrupt controller，PIC)进行编程。所以在RTX运行时，RTX可以屏蔽所有Windows 中断，从而RTX中断总能够屏蔽Windows。
另一方面，处理器级的中断屏蔽不会失效，因此不必冒风险使用x86 NMIs(不可屏蔽中断，non-maskable interrupts)。RTX采用一种静态方案解决IRQ锁定，它将多个中断优先级挂钩，这种动态挂钩功能使用旋转锁定(或者在单处理器上的基于IRQ的同步)扫描HAL，寻找这些操作的信号。
在典型的800MHZ的PC平台上，这些技术提供了小于1微秒的时钟中断最坏延迟响应时间。

RTX对象
RTSS环境拥有快捷高效的对象管理器。它支持的对象满足下列标准：
1)可用于实时编程
2)兼容Win32
IPC对象同样适用于Win32应用程序和设备驱动，允许程序员最大限度的发挥Windows的性能。IPC设置包括互斥体，事件，信号量和共享内存对象。
RTSS对象管理器使用Windows的不分页内存池以满足它的存储需要。使用Windows提供的机制可以减少RTX的资源消耗，但是对象的分配是不确定的。

RTSS调度器
RTSS调度器采用抢占式策略实现优先级，它可以提升优先级以防止优先级倒置。RTSS环境提供了128种优先级，序号从0到127，0代表最低优先权。RTSS调度器总是在准备运行的线程中运行优先级最高的(当多个准备运行的线程处于同一优先级时，等待时间最长的线程最先运行)。RTSS线程会一直运行直到一个高优先级的就绪线程抢占它，或者它自动释放处理器进入等待状态，还有一种情况是分配给它的时间片用光(缺省值是无限)而另一个同优先级线程已经就绪。
调度器在编码设计阶段就被设计为满足实时处理的需要。最重要的是它的操作是低延迟的，并且不受它所管理的线程数影响。每个优先级都有自己的等待队列，是一个双向链表。这就使得对于链表的插入(表尾)和删除(表的任何位置)操作的执行时间独立于链表中的线程数。一个数组会纪录哪些链表当前是空的，这个数组是由高速的由汇编代码写成的子程序进行维护的。
当一个RTSS线程运行时，所有Windows管理的中断以及任何拥有低优先级的线程所管理的中断都一律被屏蔽掉。相反地，所有拥有高优先级的线程所管理的中断都不会被屏蔽，并且允许其打断当前线程。除了这些设备中断，其他可以导致当前线程被中断的机制包括一个使得拥有高优先级的线程就绪的定时器的到期，一个标明高优先级线程正在等待的同步对象信号(正在运行线程的同步对象)。
为了解决线程抢占的问题，RTSS采用了经典的优先级提升的解决方案[Nakajima 93] [Sha 90]。当一个低优先级线程拥有一个高优先级线程等待的对象时，在它拥有对象的时间内会被自动提升到较高的优先级别。

服务请求中断(Service Request Interrupt，SRI)
RTX的一个重要的架构特征就是Windows和RTX之间的一个无锁中断驱动接口，这个接口实现了本地程序调用(Local Procedure Call，LPC)机制。这个完全分离的架构使得RTSS能够移植到不同的环境中(例如多处理器RTX产品)，并能够保证快速而有效的实现。Windows方面的RTX驱动和RTSS环境之间的通讯是通过向两个缓存队列(每个方向一个队列)中的一个插入命令行，并初始化服务请求中断(Service Request Interrupt，SRI)来向另一方请求服务的。一个服务线程执行请求，其应答信息的传递通过另一个队列。典型的Windows到RTX的请求是一个与WaitForSingleObject 相似的IPC操作或者在RTSS对象上的释放操作。而典型的RTX到Windows的操作是页内存的分配或者I/O请求。SRI的设计倾向于减少响应时间，尽快地响应RTSS请求。

Win32到RTSS的IPC
交互环境下的IPC是RTX的一个重要特征，它允许在运行实时程序的资源更加密集的RTSS环境下紧密的集成应用程序。应用程序的其余部分运行在Win32子系统中，这一节描述了IPC的设计。

RTSS代理模型
IPC与其它Windows和RTSS之间的通信相同，使用SRI通道。由于SRI通道阻止Windows 线程进入队列直接获得RTX对象，RTX使用代理进程和线程支持IPC与Win32的隔离。当Win32线程要访问到RTX对象时，RTSS就会使用代理线程，这个模型简捷有效，它的优点如下：
· 在阻塞IPC请求时，在Windows端没有状态保留。
· 对于外部的Win32等待请求，RTSS没有特例
· 当Win32进程或线程终止后句柄和对象的清理工作自动由RTX的代理进程和线程完成。
虽然代理会涉及到内存和CPU的一些额外开销，但其简洁的设计和快速的实现使得这样做还是值得的。

控制Windows I/O管理器
为交互环境IPC保留无缝的Win32语义并且达到好的性能面临几大挑战。
当使用某个驱动的Win32线程终止时，Windows NT 4.0 DDK并不为驱动线程提供暴露的接口(Windows 2000 和Windows XP引入了全局声明机制，但还存在一定的局限)。但Win32的互斥体需要这样的机制。当某个线程终止时，被其获得而不是释放了的RTX互斥体必须被标注为“废弃的”，以表明它所保护的共享数据可能并不一致。RTX利用I/O管理器的I/O请求包(IRP ，I/O Request Packet)实现线程终止时的清除工作：每个关联到RTX Win32 DLL的线程向RTX驱动发送一个“死IRP”信号。当这个线程终止时，Windows调用IRP的取消子程序通知RTX驱动和RTSS对象层。I/O管理器提了一个强大的，富有挑战的环境，因为它的事件传送是异步的。例如，调用MJ_CLEANUP驱动调度子程序和取消子程序可以按照任何顺序，只要RTX的每个线程结构和每个进程保持严格的同步。
Win32-RTSS IPC的性能提出了另一个问题。在早期的执行过程中，一个无须争议的事实是对Win32中的RtWaitForSingleObject（） 函数的调用的总延迟平均为130毫秒，分析表明，大约40毫秒（大于30%）被消耗在Windows 的I/O管理器上。所以RTX4.2对IPC内核进行了重新编码，在Win32 IPC客户和RTX驱动之间使用了直接信号和共享内存[Tomlinson 97]。RTX用户和内核线程共享同步对象，直接与对方进行通信，这样就减少了Windows I/O管理器的总开销和总延迟。
需要注意的是，被Win32应用程序锁住的在RTX同步对象上的操作具有不确定性[Carpenter 97]：任何RTSS线程都可以抢占Windows中具有这种具有锁性质的线程，从而出现非常严重的优先级倒置的现象。但这是程序设计上的问题：锁定一个被Win32共享的对象应该留给一个非临界的RTSS线程去做。不过在多处理器RTX系统上，并且如果RTX和Windows分别运行于不同的处理器的话，这个问题可以得到改善。

快速计时器支持
在所有的PC平台上，实时的HAL提供了精度为1微秒甚至更快的时钟。如果没有任何RTSS应用程序在执行，那么在安装了RTX的系统上和没有安装RTX的系统上就没有任何时间上的区别了。

动态链接库
提到Win32就不得不提到DLL库。RTSS支持Win32 DLL API (LoadLibrary函数，GetProcAddress函数)。现在，所有在RTSS的DLL中的静态和全局变量都被链接到其上任何RTSS进程所共享。

RTSS中的结构异常处理
结构异常处理(Structured Exception Handling，SEH)是一个相对不为人知但是更为重要的Win32 和 Windows内核环境的特征。它的实现可以追溯到OS/2 和OSF UNIX中。SEH通过Microsoft C中的try/except 和 try/finally结构提供异常处理。C++异常处理在SEH之上被分层，就像libc signal/raise的调用一样使得SEH在任意一个Win32的环境下都变成必须的。这个模型的显著特征是：
· 具体编译程序的异常处理
· 具体操作系统堆栈的释放和异常调度子程序
· 用户提供的异常筛选程序
· 两极异常处理算法。首先调用具体操作系统的调度子程序扫描线程堆栈，以搜索合适的处理者，然后在必要时，调用具体操作系统的解除装置返回堆栈。
· 最后机会的缺省和用户提供的异常处理子程序
· 一套专门解决嵌套异常和释放冲突的特殊机制
RTSS SEH与Microsoft结构，处理调用规律，SEH API运行等兼容。并且，它专为实时系统设计，能够最小化RTSS线程中处理器层的中断屏蔽和分裂：
· 当通过Win32 RaiseException API产生软件异常时，Win32将产生一个软件中断；RTSS调用用户模式下的异常调度器。
· 当释放堆栈，并且在此之后设置了一个新的用户环境后，Win32 SEH将会产生一个特殊的中断，RTSS在用户模式下恢复环境。
· 当中断失效时，Window可能会编辑(移动)一个异常自陷帧，而RTSS在用户模式下完成此操作。
对于硬件异常，RTSS算法会诊断出自陷帧并调用RTSS异常调度器，然后从ISR返回到调度器，并处理异常。所以，软件异常并不对其他线程造成ISR延迟负担；而硬件异常也只是增加了单个中断的最坏响应的负担。

性能

下表显示了在一个在拥有ACPI芯片组的Pentium 4 2.4GHz处理器上运行的Windows XP重要性能指标，这个Windows XP安装了RTX 6.5.1。

表1 RTX与Windows XP的实时性能比较

操作
Windows XP Pro
RTX
SetEvent(No Switch)
1.04—5000+
0.24—1.27
SetEvent—WFSO
1.38—5000+
0.32—1.38
ReleaseMutex—WFSO
1.49—5000+
0.38—1.38
ReleaseSemaphere—WFSO
1.39—5000+
0.34—1.41
Yield
1.11—5000+
0.14—1.14
Priority Change
1.31—5000+
0.28—1.29
IST Latency
4.30—5000+
0.50—16.0
测试硬件（P4 2.4GHz）(Min / Max in μ sec)

在Windows频繁装载下的关键RTX线程切换调节（最大值包括定时器中断处理的消耗）。不包含RTX和Microsoft Windows CE 的Windows作为比较，时间单位为微秒。

图2 RTSS计时器中断延迟柱状图(典型的Windows工作负载：磁盘搜索，视频升级，网络活动，屏幕保护等。X轴以微秒为单位，Y轴是按对数显示的采样数值。较低的有阴影的部分代表最后一秒的活动，较高的部分显示的是总体运行的积累量)

图3 和图2相同工作量的Win32计时器中断延迟直方图
通过对RTX6.5.1的独立测试，可以发现RTX的丰富性能[OMAC 98] [Real-Time 98] [Timmerman 98]。当然不要忘记RTX6.5.1提供了更快地线程切换计时器。

使用Visual Studio创建RTX应用程序
通过RTX提供的头文件和库函数，RTX应用程序可以像其他任何Windows应用程序一样被Microsoft Visual Studio编译和链接。application wizard可以用来更改工程设置和创建源代码框架。从RTX5.1开始，Visual Studio debugger可以像调试其他Win32进程一样调试运行RTX进程。进程与线程的变量和断点可以被设置和管理。RTX包括大量的应用工具，其中有图4中显示的RTSS Object Viewer。

图4 对RTSS Object Viewer的截屏(显示出了一个拥有两个线
程的单进程，一个线程是计时器，另一个是共享内存对象)

性能工具
RTX性能工具使得开发者可以在他们自己的平台上对性能进行评价和调整。Ksrtm是一个驱动程序，也是用于HAL层和计时器中断延迟衡量的Win32工具。由于在内核中运行，使其对缓存的响应相应迟钝。Ksrtm也可以发现究竟哪一个Windows的平台组件或设备驱动造成了最大的延迟。在此之后，Ksrtm ISR从堆栈中得到了中断序列的地址，然后将其分派到一个装载完毕的Windows内核模块中。Srtm应用程序是一个可以在RTX或者Win32环境下运行的测量RTX API计时器时间延迟的工具，它通过直方图忠实的显示出应用程序观察到的计时器延迟。Lpt工具对由总线控制事件引起的长延迟事件起决定作用。最后，Platform Evaluator是一个图形用户接口程序(基于GUI的)，它可以衡量一个在不同工作量下的平台的响应时间特性。

目标设计者SLD
除了支持Windows的零售版，RTX run-time环境也被打包为一个SLD，供Windows XP Embedded的目标设计者使用。因为RTX可以被配置为在启动时自动运行RTSS进程，即使只有最小的脚本配置，Windows XP Embedded也会包括RTSS应用程序并在启动序列中优先将其装载（甚至在Win32环境启动前）。

未来方向
现在，RTX满足了很多用户的需求。但是还有更多的用户资源等待我们的开发。

多处理
RTX的最初版本只能运行在单处理器系统上。最近的版本支持了多处理器系统，但是这种多处理器系统必须遵循Intel 多处理器规范1.4版才行。这个规范提供了被先进可编程中断控制器(Advanced Programmable Interrupt Controller，APIC)所控制的中断，这种中断适合于多处理器系统。通过APIC，不同的中断可以被引导至不同的处理器。RTSS使用系统中的一个处理器专门运行RTSS线程，而剩下的处理器运行Windows线程。这有效的减少了实时线程的延迟，同时也防止了在单处理器系统中出现的Windows线程饿死的情况。RTX5.1也允许RTSS处理器被Windows 共享，这种情况同于单处理器。

即插即用设备和电源管理
从RTX5.0以后，适用于Windows 的即插即用设备和电源管理就被集成到RTX中来。RTX和Windows 协同工作，管理在他们之上的设备资源，所以在ACPI平台上中断被动态分配到PCI设备上以最小化中断冲突。当RTX应用程序运行时，RTX阻止Windows将电源调节到低工状态干扰RTX的实时性能。

适用环境
RTSS可以当作其他实时环境的基础，譬如Java[Nilsen 98] [Nilsen & Lee 98].。

结论
Ardence的RTX表明，通过选择合适的实时系统扩展，有可能使Windows平台在保证其作为通用平台特征的基础上提供实时操作系统的特征。所合成的系统在提供了实时系统所需要的确定性的同时，保证了平台为更广泛的人群提供更为熟悉的操作环境。

获取渠道
获取RTX可以从美斯比的网站上获取。
参考
[Anschuetz 98] E. Anschuetz, M. Biddle, S. Giambarberee, B. Riner, J. Dube, Real Time Flight Simulators Under NT, Proceedings of the 1998 Interservice/Industry Training, Simulation and Education Conference (I/ITSEC December 1998).
[Baker 97] Art Baker, The Windows NT Device Driver Book, Prentice Hall, 1997.

[Bollella 95] G. Bollella and K. Jeffay, Support For Real-Time Computing Within General Purpose Operating Systems: Supporting co-resident operating systems, Proc. IEEE Real-Time Technology and Applications Symposium Chicago, IL, May 1995.

[Carpenter 97] Bill Carpenter, Mark Roman, Nick Vasilatos, Myron Zimmerman, The RTX Real-Time Subsystem for Windows NT, Usenix Windows NT Symposium, 1997.

[Jones 98] C. Jones, M. Cherepov, Windows-based systems and the Win32 API, Real-Time Magazine 98/3.

[Microsoft 95] Microsoft, Real-Time Systems and Microsoft Windows NT.

[Nakajima 93] T.Nakajima, T.Kitayama, H.Arakawa, H.Tokuda, Integrated Management of Priority Inversion in Real-Time Mach, IEEE Real-Time Systems Symposium, December 1993.

[Nilsen 98] Kelvin Nilsen, Simanta Mitra, Sairam Sankaranarayananan, Venkatesh Thanuvan, Asynchronous Java Exception Handling in a Real-Time Context, Workshop on Programming Languages for Real-Time Industrial Applications '98, Madrid, Spain, December 1, 1998.

[Nilsen & Lee 98] Kelvin Nilsen, Steve Lee, Perk(TM) Real-Time API, July 1998, Newmonics, Inc.

[OMAC 98] Open Modular Architecture Controls (OMAC) Users Group, Hard Real-time Extensions of Windows NT Evaluation Report Test Plan and Phase 1 & 2.

[Ramamritham 98] Krithi Ramamritham, Chia Shen, Oscar Gonzalez, Shubo Sen, Shreedhar B Shirgurkar, Using Windows NT for Real-Time Applications: Experimental Observations and Recommendations Proceedings of IEEE RTAS'98 (the IEEE Real-Time Technology and Applications Symposium), June 3-5, 1998. Denver, Colorado.

[Real-Time 98] Real-Time Magazine, Windows NT RT Extensions - Evaluation Reports.

[Sha 90] L. Sha, R. Rajkumar, and J. P. Lehoczky, Priority Inheritance Protocols: An Approach to Real-Time Synchronization, IEEE Transactions on Computers, 39 (9):1175-1185, September 1990.

[Solomon 98] David A. Solomon, Inside Windows NT, Second Edition, Microsoft Press, 1988.

[Sommer 96] Sommer, S., Removing Priority Inversion from an Operating System, Proceedings of the Nineteenth Australasian Computer Sc