RTX技术文章V1.3.doc

1、RTX Real-Time Extension for Control of Windows技术白皮书美国 Ardence公司北京美斯比科技有限公司摘要随着实时嵌入式技术的发展，Windows 系列操作系统越来越多的被考虑作为实时系统的应用平台。为了满足硬实时系统严格的响应时间要求，增加Windows 系统的实时能力非常必要。这篇文章介绍了美国 Ardence 公司的RTX 产品，RTX 在 Windows 平台上提供了一个实时子系统，实现了确定性的实时线程调度、实时环境和与原始 Windows 环境之间的进程间通讯机制以及其它只在特定的实时操作系统中才有的对 Windows 系统的扩展特性。

2、这篇文章描述了 RTX 怎样提供这些特性和目前的实时性能，并指出了未来性能增强的方向。目录简介Windows 平台和实时系统RTX 结构深入 RTX实时硬件抽象层Windows 停止保护扩展 HALRTX 和中断延迟RTX 中断延迟缩减技术RTX 对象RTSS 调度器服务请求中断Win32 到 RTSS 的 IPCRTSS 代理模型控制 Windows I/O 管理器快速计时器支持动态链接库RTSS 中的结构异常处理性能使用 Visual Studio 创建 RTX 应用程序性能工具目标设计者 SLD未来方向结论获取渠道参考简介微软公司的 Windows 系列操作系统的大众接受程度和市场占有率

3、日益扩大。这主要是基于以下几点原因： Windows 平台更强的性能和更低的价格； 该平台上可运行多种应用程序； 该平台支持多种开发工具； 丰富的 Win32 应用程序接口； 大量的熟悉本系统的开发支持人员和最终用户。鉴于多系统的计算环境的复杂度和所需要的额外维护成本，更多的公司倾向于将 Windows 应用到设备的所有级别上。将其作为网络服务器或者桌面系统是很容易理解的，因为 Windows 就是为这些环境而设计的。但是，仍然有很多其他环境有使用 Windows 的要求，譬如制造车间，医疗设备，仿真器械，测试设备和通信器材。这些环境的共同特点就是它们都要求系统拥有硬实时特性。Windows

4、可以满足这个需要吗？答案是否定的。但是，通过附加软件就可以在 Windows 上实现所需要的硬实时特性。否则的话，开发者必须增加一台实时计算机，并承担额外的费用和复杂度。下文讨论了 Ardence 公司的硬实时产品 RTX，其中包括 RTSS 实时子系统（Real-Time Sub-System） ，它是专门为PC 架构的 Windows 平台设计的。此前的一篇文章Carpenter 97讨论了开发过程中的一些成果，这篇文章提供了对实现的更详细的介绍，包括性能参数，功能的提高以及发展前景的概述。Windows 平台和实时系统什么样的系统可以被称为实时？实时系统的特点在于：一个正确的运行不仅取决

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

6、有很多优先级的多线程优先级调度器； 可预测的线程同步机制； 具有优先级继承 快速的时钟和定时器为什么 Windows 平台不是实时的？Windows 是一个通用操作系统平台，同时适合于桌面交互系统和网络服务器Solomon 98。Windows 在实时应用方面的缺点已经被很系统地研究过了： 线程优先级太少； 隐含的不确定的线程调度机制； 优先级倒置，尤其体现在中断处理中；尽管更快的处理器显著的增加了处理能力和平均响应时间，甚至使某些人以为实现系统的实时性变为可能，但是非确定性系统是不能变成确定系统的，最坏响应时间的提高也不是总能被保证的。所以，新的硬件平台并不能改变Windows 的实时特性。

7、某些开发人员使用了两台计算机-一台运行 Windows，另一台运行实时系统。但是这增加了大量的硬件成本并使系统的开发和集成变得复杂，不是一种通用的、高效率的解决方案。为什么要对 Windows 平台进行实时扩展？RTX 的设计逻辑基于以下几个因素。通用的 Windows 操作系统是面向大众市场的，不适合实时性这样非普遍的需求。尽管由微软赞助的关于 Windows实时性的研究已经有了一些进展Sommer 96-尤其当应用程序事先声明其资源需要的时候Sommer 97Sommer & Potter 96 -但对于 Windows 这种面向广阔市场的操作系统，吸收实时性系统的复杂性以完成其功能，其可

8、行性是值得怀疑的Microsoft 95。这意味着使 Windows 具有实时性的最好方法是通过对原产品的扩展或者由插件实现Jones 98。同时，Windows 平台提供了丰富的和复杂的设备驱动模型，定制的硬件抽象层(hardware abstraction layer ，HAL)和模型为开发者提供了对系统行为的灵活掌控能力和面对技术挑战的创造性机会。这样，实时功能可以按照微软Windows 驱动开发工具(Driver Development Kit，DDK)和 HAL 模型来实现Baker 97。最后，对于非微软员工的 Windows 扩展内核编写人员，Windows 的内核就如同硅制芯片

9、一样，其接口和行为都是固定的。无需抱怨，利用现有的条件就可以设计出紧凑的实时性扩展，使其易于在不同的 Windows 版本之间进行移植。图 1 说明了 RTX 如何实现可移植性的目标。图 1 RTX 架构那么，你需要一个硬实时的 Windows 环境吗？为何将 Windows 扩展为实时系统？既然刚才提到的微软 Windows 平台的许多缺点都是由于其线程模型和线程调度，那么实时扩展拥有自己的线程和调度也就十分必要了。同样，Windows 平台的同步对象，例如事件，信号量，互斥体等缺乏必要的实时机制(尤其它们既无法防止线程侵占，又无法使线程按优先级顺序等待对象响应)。由于这些原因，实时扩展应该

10、实现自己的同步对象Bollella 95。如果按照 Windows 的环境逻辑实现一个实时子系统，这个实时环境应该能够： 无论在任何时间其优先级都应该高于 Windows，至少在 Windows 中断处理程序代码的临界区以外。 执行实时任务时，延迟 Windows 的中断和错误。 实行实时任务时，要能够处理实时中断。抢占 Windows 和其驱动的高级别中断请求 (Interrupt Request Number，IRQ)让给没有时间约束的实时任务是一种危险的想法。但是这些事件是常见的，并且 Windows 被设计用来处理它们：高优先级中断请求(high-interrupt request l

11、evel， IRQL)侵占低级的；DMA 外设的总线控制和系统管理模式下的处理可以延迟最高级别的中断请求；PCI 设备可以拖延 CPU 对 I/O 空间的访问。所以，从 Windows 的观点来看，RTSS 窃取 Windows 的执行周期就等同于获得中断并返回。这样的时间能被 Windows 很好的处理，而不必考虑其持续时间。实时子系统的功能需要包括与 Win32 子系统的进程间通讯(interprocess communication，IPC)，访问 Windows 内核功能( 中断管理，I/O 端口，关机/崩溃处理器)，最重要的是与 Win32 在源代码级别上兼容。RTX 结构RTX 被

12、实现为一套库的集合(动态库与静态库)，RTSS 作为 Windows 的内核设备驱动与 HAL 扩展( 见图 1)Carpenter 97。子系统实现前面提到的实时对象和调度器。通过一套被称作 RtWinAPI 的实时 API(RtWinAPI 同时也被Windows CE 和 Phar Lap ETS 支持)这套库提供了对这些对象的访问方法。注意，RtWinAPI 可以被标准 Win32 环境和 RTSS 环境调用。虽然在 Win32 环境中使用 RtWinAPI 不能提供在 RTSS 下的确定性，但是却可以允许应用程序在更加友好的 Win32 编程环境中开发而不是 DDK 环境Anschu

13、etz 98。将Win32 程序转化为 RTX 程序只需要重新链接一套不同的库而已。Windows 服务控制管理器直接将 RTX 进程和动态链接库(DLL) 的可执行映像装入内核的不分页内存中。深入 RTX实时硬件抽象层(HAL )HAL 是 Windows 系统提供的可被用来进行修改和扩展的资源的一部分。RTX 修改 HAL 有以下 3 个目的： 在 Windows 和 RTX 线程之间增加独立的中断间隔； 实现高速时钟和定时器； 实现关闭处理程序。中断隔离意味着 Windows 线程和 Windows 管理的设备不可能中断 RTSS，同时 Windows 线程也不能屏蔽 RTSS 管理的设

14、备。HAL 通过控制处理器级的中断屏蔽满足这些条件。当运行 RTSS 线程时，所有 Windows 控制的中断都被屏蔽掉。当 Windows 线程请求设置中断屏蔽时，作为实际管理中断屏蔽的软件，HAL 确保没有任何 RTSS 中断被屏蔽。Windows 提供的计时器的定时周期为 1000 微秒(1 毫秒) 。RT-HAL 将其降到了 100 微秒并且提供了同步(与计时器)的时钟，其最小分辨率为 100 纳秒。Windows 停止保护除了中断管理和更快的定时器服务，实时 HAL 也提供了 Windows 关机管理。当 Windows 正常关机或者蓝屏崩溃时， RTSS 应用程序可以被关联到Win

15、dows 关机管理器。正常关机允许 RTSS 不受影响的继续运行，直到所有的 RTSS 关机处理器返回。但当出现蓝屏时，RTSS 关机处理器就会受到限制，它将无法调用 Windows 的服务(例如分配新内存)。在实际中，这意味着当系统正常关机或者崩溃时，关机处理器清除一切并复位硬件，还可能向操作者发出警告，或者切换到备用状态。扩展 HAL自从 RTX4.3，一直采用扩展 HAL 的方式而不是替代。HAL 扩展驱动在操作系统初始化时启动(SERVICE_SYSTEM_START) ，在内存中完成对 HAL 的动态检测、中断截取、定时器和关机的相关调用，并且重定向到 RTX 的相应位置。这种二进制

16、钩子技术比起替代 HAL 来有许多优点： RTX 可以处理很广泛的 OEM 平台，这种重定向调用被限制在一种对于不同的 OEM 和服务商之间很少区别的调用上。 RTX 兼容更大范围的 Windows 补丁包(Service Pack，SP)，为了配合最新的 HAL 资源的补丁包而修改 RTX 是不必要的。 因为磁盘上的 HAL 未被改动，所以安装变得更加容易，因此 RTX 也不受 SP 升级的影响。 升级到更新的 Windows 版本变得容易，不费什么力气。当 RTX 在 Windows 2000 和 XP 的后续 SP 上不经修改的成功安装，扩展HAL 的好处也就无需证明了。RTX 和中断延

17、迟软件引起的中断当 RTX 高速时钟或者其他设备产生 RTX 中断时，就会发生从 Windows到 RTX 的转换。所以，为达到 RTX 的 ISR 的确定性就必须减少 Windows 的中断延迟。让我们先来考察一下在没有 RTX 的情况下 Windows 平台的 ISR 延迟来源。最显著的延迟是由 Windows 内核和驱动引起的 IRQ 屏蔽，一般是通过Windows 的 KeRaise/LowerIrql 函数调用在几毫秒内实现的。Windows 内核，HAL 和某些特殊驱动也通过 x86 STI/CLI 指令集在几微秒内完成处理器级的中断屏蔽。Windows 和 RTX 中断处理自动会

18、屏蔽中断，所以也肯定会增加 ISR 延迟。虽然在很多情况下 Windows 非常依赖于中断处理(例如软件异常，释放线程堆栈)，但其中断顺序依然取决于最坏情况下的延时。硬件引起的中断和硬件有关的最明显的问题就是应用程序和操作系统对高速缓存的污染和转储清除。TLB 的重填也属于这种情况。视频驱动的缓存占有量是极大的，当RTX 中断启动时会造成竞争性的转储清除。当应用程序引起缓存污染时，ISR的直方图上将出现典型的双驼峰型。大部分采样靠近最好情况的区域，另外一大部分靠近存储清除的区域(见图 2)。电源管理，尤其是当其在移动设备上，当 CPU 经过较长时间的停滞而处于低耗电量状态时偶尔会产生较长的延迟

19、。这种问题很容易被侦查到。一个典型的系统可以通过 BIOS 的设置来禁止这些特性。某些系统，尤其是笔记本，使用 Pentium 处理器的系统管理模式(System Management Mode，SMM) 在 BIOS 固化软件中完成敲击键盘和其他处理。同时，在 SMM 下，处理器不会处理增加 ISR 延迟的中断。幸运的是，新一代系统平台通过高级设置与电源接口(Advanced Configuration and Power Interface，ACPI)和 Windows 2000 转而使用操作系统而不是 BIOS 提供电源管理。因此，这些延迟的原因已经变得微不足道了。总线控制事件会引起 C

20、PU 长时间的延迟。这种情况包括小型电脑系统接口(small computer system interface ，SCSI)设备的高性能 DMA 所引起的数微秒的 CPU 延迟和为响应 CPU 访问而加入等待周期的显卡。有时这些外设的行为可以被驱动控制，通过交替处理从而减少延迟。虽然没有任何系统能够确保应用程序不受这些硬件因素的干扰，但是 RTX提供了诊断平台相关延迟的诊断工具，可以辨别那些行为错误的外设。留意这些因素并使用 RTX 工具来衡量开发平台对于一个系统的整体性能来说是非常重要的。RTX 中断延迟缩减技术RTSS 完全消除了由 Windows 平台及其驱动的 IRQL 屏蔽所造成的

21、延迟。当系统在 Windows 与 RTX 之间进行切换时，RT-HAL 执行中断隔离，重新对可编程中断控制器(programmable interrupt controller，PIC)进行编程。所以在RTX 运行时，RTX 可以屏蔽所有 Windows 中断，从而 RTX 中断总能够屏蔽Windows。另一方面，处理器级的中断屏蔽不会失效，因此不必冒风险使用 x86 NMIs(不可屏蔽中断， non-maskable interrupts)。 RTX 采用一种静态方案解决IRQ 锁定，它将多个中断优先级挂钩，这种动态挂钩功能使用旋转锁定 (或者在单处理器上的基于 IRQ 的同步)扫描 HA

22、L，寻找这些操作的信号。在典型的 800MHZ 的 PC 平台上，这些技术提供了小于 1 微秒的时钟中断最坏延迟响应时间。RTX 对象RTSS 环境拥有快捷高效的对象管理器。它支持的对象满足下列标准：1)可用于实时编程2)兼容 Win32IPC 对象同样适用于 Win32 应用程序和设备驱动，允许程序员最大限度的发挥 Windows 的性能。IPC 设置包括互斥体，事件，信号量和共享内存对象。RTSS 对象管理器使用 Windows 的不分页内存池以满足它的存储需要。使用 Windows 提供的机制可以减少 RTX 的资源消耗，但是对象的分配是不确定的。RTSS 调度器RTSS 调度器采用抢占

23、式策略实现优先级，它可以提升优先级以防止优先级倒置。RTSS 环境提供了 128 种优先级，序号从 0 到 127，0 代表最低优先权。RTSS 调度器总是在准备运行的线程中运行优先级最高的(当多个准备运行的线程处于同一优先级时，等待时间最长的线程最先运行)。RTSS 线程会一直运行直到一个高优先级的就绪线程抢占它，或者它自动释放处理器进入等待状态，还有一种情况是分配给它的时间片用光(缺省值是无限)而另一个同优先级线程已经就绪。调度器在编码设计阶段就被设计为满足实时处理的需要。最重要的是它的操作是低延迟的，并且不受它所管理的线程数影响。每个优先级都有自己的等待队列，是一个双向链表。这就使得对于

24、链表的插入(表尾)和删除(表的任何位置)操作的执行时间独立于链表中的线程数。一个数组会纪录哪些链表当前是空的，这个数组是由高速的由汇编代码写成的子程序进行维护的。当一个 RTSS 线程运行时，所有 Windows 管理的中断以及任何拥有低优先级的线程所管理的中断都一律被屏蔽掉。相反地，所有拥有高优先级的线程所管理的中断都不会被屏蔽，并且允许其打断当前线程。除了这些设备中断，其他可以导致当前线程被中断的机制包括一个使得拥有高优先级的线程就绪的定时器的到期，一个标明高优先级线程正在等待的同步对象信号(正在运行线程的同步对象) 。为了解决线程抢占的问题，RTSS 采用了经典的优先级提升的解决方案Na

25、kajima 93 Sha 90。当一个低优先级线程拥有一个高优先级线程等待的对象时，在它拥有对象的时间内会被自动提升到较高的优先级别。服务请求中断(Service Request Interrupt，SRI)RTX 的一个重要的架构特征就是 Windows 和 RTX 之间的一个无锁中断驱动接口，这个接口实现了本地程序调用(Local Procedure Call，LPC)机制。这个完全分离的架构使得 RTSS 能够移植到不同的环境中(例如多处理器 RTX 产品)，并能够保证快速而有效的实现。Windows 方面的 RTX 驱动和 RTSS 环境之间的通讯是通过向两个缓存队列(每个方向一个队

26、列)中的一个插入命令行，并初始化服务请求中断(Service Request Interrupt，SRI)来向另一方请求服务的。一个服务线程执行请求，其应答信息的传递通过另一个队列。典型的Windows 到 RTX 的请求是一个与 WaitForSingleObject 相似的 IPC 操作或者在 RTSS 对象上的释放操作。而典型的 RTX 到 Windows 的操作是页内存的分配或者 I/O 请求。SRI 的设计倾向于减少响应时间，尽快地响应 RTSS 请求。Win32 到 RTSS 的 IPC交互环境下的 IPC 是 RTX 的一个重要特征，它允许在运行实时程序的资源更加密集的 RTSS

27、 环境下紧密的集成应用程序。应用程序的其余部分运行在Win32 子系统中，这一节描述了 IPC 的设计。RTSS 代理模型IPC 与其它 Windows 和 RTSS 之间的通信相同，使用 SRI 通道。由于 SRI通道阻止 Windows 线程进入队列直接获得 RTX 对象，RTX 使用代理进程和线程支持 IPC 与 Win32 的隔离。当 Win32 线程要访问到 RTX 对象时，RTSS 就会使用代理线程，这个模型简捷有效，它的优点如下： 在阻塞 IPC 请求时，在 Windows 端没有状态保留。 对于外部的 Win32 等待请求，RTSS 没有特例 当 Win32 进程或线程终止后句

28、柄和对象的清理工作自动由 RTX 的代理进程和线程完成。虽然代理会涉及到内存和 CPU 的一些额外开销，但其简洁的设计和快速的实现使得这样做还是值得的。控制 Windows I/O 管理器为交互环境 IPC 保留无缝的 Win32 语义并且达到好的性能面临几大挑战。当使用某个驱动的 Win32 线程终止时，Windows NT 4.0 DDK 并不为驱动线程提供暴露的接口(Windows 2000 和 Windows XP 引入了全局声明机制，但还存在一定的局限)。但 Win32 的互斥体需要这样的机制。当某个线程终止时，被其获得而不是释放了的 RTX 互斥体必须被标注为“废弃的” ，以表明它

29、所保护的共享数据可能并不一致。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 的性能提出了另一个问题。在

30、早期的执行过程中，一个无须争议的事实是对 Win32 中的 RtWaitForSingleObject（） 函数的调用的总延迟平均为 130 毫秒，分析表明，大约 40 毫秒（大于 30%）被消耗在Windows 的 I/O 管理器上。所以 RTX4.2 对 IPC 内核进行了重新编码，在Win32 IPC 客户和 RTX 驱动之间使用了直接信号和共享内存Tomlinson 97。RTX 用户和内核线程共享同步对象，直接与对方进行通信，这样就减少了Windows I/O 管理器的总开销和总延迟。需要注意的是，被 Win32 应用程序锁住的在 RTX 同步对象上的操作具有不确定性Carpente

31、r 97：任何 RTSS 线程都可以抢占 Windows 中具有这种具有锁性质的线程，从而出现非常严重的优先级倒置的现象。但这是程序设计上的问题：锁定一个被 Win32 共享的对象应该留给一个非临界的 RTSS 线程去做。不过在多处理器 RTX 系统上，并且如果 RTX 和 Windows 分别运行于不同的处理器的话，这个问题可以得到改善。快速计时器支持在所有的 PC 平台上，实时的 HAL 提供了精度为 1 微秒甚至更快的时钟。如果没有任何 RTSS 应用程序在执行，那么在安装了 RTX 的系统上和没有安装 RTX 的系统上就没有任何时间上的区别了。动态链接库提到 Win32 就不得不提到

32、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+ 异常处理在 SE

33、H 之上被分层，就像 libc signal/raise的调用一样使得 SEH 在任意一个 Win32 的环境下都变成必须的。这个模型的显著特征是： 具体编译程序的异常处理 具体操作系统堆栈的释放和异常调度子程序 用户提供的异常筛选程序 两极异常处理算法。首先调用具体操作系统的调度子程序扫描线程堆栈，以搜索合适的处理者，然后在必要时，调用具体操作系统的解除装置返回堆栈。 最后机会的缺省和用户提供的异常处理子程序 一套专门解决嵌套异常和释放冲突的特殊机制RTSS SEH 与 Microsoft 结构，处理调用规律，SEH API 运行等兼容。并且，它专为实时系统设计，能够最小化 RTSS 线程中

34、处理器层的中断屏蔽和分裂： 当通过 Win32 RaiseException API 产生软件异常时，Win32 将产生一个软件中断；RTSS 调用用户模式下的异常调度器。 当释放堆栈，并且在此之后设置了一个新的用户环境后，Win32 SEH 将会产生一个特殊的中断，RTSS 在用户模式下恢复环境。 当中断失效时，Window 可能会编辑(移动)一个异常自陷帧，而 RTSS在用户模式下完成此操作。对于硬件异常，RTSS 算法会诊断出自陷帧并调用 RTSS 异常调度器，然后从 ISR 返回到调度器，并处理异常。所以，软件异常并不对其他线程造成 ISR延迟负担；而硬件异常也只是增加了单个中断的最坏响应的负担。性能