-
使用
RTX
增加
Win
dows XP/2000/XP
Embedded
系统的硬实时特性收藏
内容简介
摘要
简介
Windows
XP
平台和实时系统
RTX
结构
深入
RTX
实时硬件抽象层
Windows
XP
停止保护
扩展
HAL
RTX
和中断延迟
RTX
中断延迟缩减技术
RTX
对象
RTSS
调度器
服务请求中断
Win32
到
RTSS
的
IPC
RTSS
代理模型
控制
Windows XP
I/O
管理器
快速计时器支持
动态链接库
RTSS
中的结构异常处理
性能
使用
Visual Studio
创建
RTX
应用程序
性能工具
目标设计者
SLD
未来方向
结论
获取渠道
参考
摘要
由于很多商业和技术原因，
Microsoft?
Windows NT?
、
Microsoft
Windows 2000
、
Windows
XP
和
Windows XP Emb
edded
操作系统越来越多被考虑作为实时系统平台。为了满足硬实时
系统严格的响应时间的要求，增加
Windows XP
系统的实时能力非常必要。这篇文章介绍了
美国
Ardenc
e
公司的
RTX
产品，
其在
Windows
平台上提供了一个实时子系统。<
/p>
RTX
实现了确
定性的实时线程调度、实
时环境和与原始
Windows
环境之间的进程间通讯机制以及
其它只
在特定的实时操作系统中才有的对
Windows
系统的扩展特性。这篇文章描述了
RTX
怎样
提
供这些特性和目前的实时性能，并指出了未来性能增强的方向。
简介
微软公司的
Windows XP
操作
系统的大众接受程度和市场占有率日益扩大。这主要是基
于以下几点原因：
?
Windows
XP
平台更强的性能和更低的价格；
?该平台上可运行多种应用程序；
?该平台支持多种开发工具；
?丰富的
Win32
应用程序接口；
?大量的熟悉本系统的开发支持人员和最终用户。
鉴于多系统的计算环境的复杂度和
所需要的额外维护成本，更多的公司倾向于将
Windows XP
应用到设备的所有级别上。
将其作为网络服务器或者桌面系统是很容易理解的，
因为
Windows XP
就是为这些环境
而设计的。
但是，
仍然有很多其他环境有使用
< br>Windows XP
的要求，譬如制造车间，医疗设备，仿真器械，测试设备和
通信器材。这些环境的共同特点
就是它们都要求系统拥有硬实时特性。
< br>
Windows
XP
可以满足这个需要吗？答案是否定的。但是，通过附加软件就可以
在
Windows
XP
上实现所需要
的硬实时特性。否则的话，开发者必须增加一台实时计算机，并
承担额外的费用和复杂度
。下文讨论了
Ardence
公司的硬实时产品
RTX
，其中包括
RTSS
实
时子系统（
Real-Time Sub-System
）
，它是专门为
PC
架构（
Intel Pentium
系列及其相应的操作
系统）的
Windows
平台设计的。
此前的一篇文章
[Carpenter 97]
讨论了开发过程中的一些成果，
这篇文章提供了对实现的
更详细的介绍，包括性能参数，功能的提高以及发展前景的概述。
Windows
XP
平台和实时系统
什么样的系统可以被称为实时？
实时系统的特点在于：一个正确的运行不仅取决于结果的准确
，更取决于实现的时间。
需要注意的是，
“实时”并不意味着“
快”
，它指的是系统的时间响应特性。换句话说，实时
性的衡量
标准不是系统的平均响应时间而是最坏情况下的响应时间。
实时系统有时被进一步
划分为硬实时系统和软实时系统。
硬实时系统对响应时间的要求是严格
的，
绝对的；
而软实
时系统允许有一些
小的误差。
某些观点认为
“软实时”
的
说法是自相矛盾的，
在下文中凡涉
及到“实时”都指的是硬实时
系统。
一个硬实时系统的例子是压盖机给在传送带上传送的瓶子加盖。
对于系统，
仅仅准确定
位压盖机是不够的，
如果瓶盖已经移走而
压盖机才刚刚到位那么所有的精确定位都是徒劳的。
除了确定性，实时系统通常还有一些其他要求：
?一个具有很多优先级的多线程优
先级调度器
(
如典型的
64-256)
；
?可预测的线程同步机制；
?具有优先级继承
?快速的时钟和定时器
为什么
Windows
XP
平台不是实时的？
Windows
XP
是一个通用
操作系统平
台，同时适
< br>合于桌面交
互系统和网
络服务器
[Solomon 98]
。
Windows
XP(
同时适用于
Windows XP Embedded)
在实时应用方面的缺点已经被
很系统地研究过了：
?线程优先级太少；
?隐含的不确定的线程调度机制；
?优先级倒置，尤其体现在中断处理中；
尽管更快的处理器显著的增加了处
理能力和平均响应时间，
甚至使某些人以为实现系统
的实时性变
为可能，
但是非确定性系统是不能变成确定系统的，
最坏响应时
间的提高也不是
总能被保证的。所以，新的硬件平台并不能改变
Windows XP
的实时特性。
某些开发人员使用了两台计算机
--
--
一台运行
Windows XP
，
另一台运行实时系统。
但是
这增加了
大量的硬件成本并使系统的开发和集成变得复杂，
不是一种通用的、
高效率的解决
方案。
为什么要对
Windows XP
平台进行实时扩展？
RTX
的设计逻辑基于以下几个因素
。通用的
Windows
XP
操作系
统是面向大众市场的，
不适合实时性这样非普遍的需求。尽管由微软赞助的关于
Windows XP
实时性的研究已经有
了<
/p>
一
些
进
展
[Sommer
96]----
尤
其
当
应
用
程
序
事
先
< br>声
明
其
资
源
需
要
的
时
候
[Sommer
97][Sommer& Potter 96]
----
但对于
Windows XP
这种面向广阔市场的操作系统，
吸收实时性系
统的复杂性以完成
其功能，其可行性是值得怀疑的
[Microsoft
95]
。这意味着使
Windows
XP
具有实时性的最好方法是通过对原产品的扩展或者由插件实
现
[Jones 98]
。
同时，
Windows
XP
平台提供了丰富的和复杂的设备驱动模型，定制的硬件抽象层
(hard
ware abstraction layer
，
HAL)
和模型为开发者提供了对系统行为的灵活掌控能力和面对
技术挑
战的创造性机会。这样，实时功能可以按照微软
Windows
XP
驱动开发工具
(Driver
Development Kit
，
D
DK)
和
HAL
模型来实现
[Baker 97]
。
最后，
对
于非微软员工的
Windows
XP
扩展内核编写人员，
Windows XP
的内核就如同硅
制芯片一样，
其接口和行为都是固定的
。
无需抱怨，
利用现有的条件就可以设计出紧凑的实
时性扩展，使其易于在不同的
Windows
版本
之间进行移植。图
1
说明了
RTX
如何实现可移
植性的目标。
那么，你需要一个硬实时的
Windows
XP
环境吗？
为何将
Windows
XP
扩展为实时系统？
既然刚才提到的微软
Windows
XP
平台的许多缺点都是由于其线程模型和线程调度，那
么实时
扩展拥有自己的线程和调度也就十分必要了。同样，
Windows
< br>XP
平台的同步对象，
例如事件，信号量，互斥体等缺乏
必要的实时机制
(
尤其它们既无法防止线程侵占，又无法
使线程按优先级顺序等待对象响应
)
。由于这
些原因，实时扩展应该实现自己的同步对象
[Bollella
95]
。
如果按照
Windows
XP
的环境逻辑实现一个实时子系统，这个实时环境应该能够：
?无论在任何时间其优先级都应该高于
Windows
XP
，至少在
Windows
XP
中断处理程序
代码的临界区以外。
?执行实时任务时，延迟
Windows
XP
的中断和错误。
?实行实时任务时，要能够处理实时中断。
抢占
Windows
XP
和其驱动的高级别中断请求
(Interrupt
Request Number
，
IRQ)
让给没有
时间约束的实时任务是一种危险的想法。但是这些事件是常见的，并且
Windows XP
被设计
用来处理它们
：
高优先级中断请求
(high-interrupt
request level
，
IRQL)
侵占低级的；
DMA
外设
的总线控
制和系统管理模式下的处理可以延迟最高级别的中断请求；
PCI
设备可以拖延
CPU
对
I/O
空间的访问。所以，从
Windows
XP
的观点来看，
RTSS
窃取
Windows
XP
的执行周期
就等同于获得中断并返回。这样的时间能被
Windows XP
很好的处理，而不必考虑其持续时
间。
实时子系统的功能需要包括与
Win32
子系统的进程间通讯
(inte
rprocess communication
，
IPC)<
/p>
，访问
Windows
XP
内核功能
(
中断管理，
I
/O
端口，关机
/
崩溃处理器
)
，最重要的是与
Win32
< br>在源代码级别上兼容。
RTX
结构
RTX
被实现为一套库的集合
(
动态库与静态库
)
，
RT
SS
作为
Windows
XP
的内核设备驱动
与
HAL
扩展
(
见图
1)[Carpent
er
97]
。子系统实现前面提到的实时对象和调度器。通过
一套被
称作
RtWinAPI
的实时<
/p>
API(RtWinAPI
同时也被
Wi
ndows
CE
和
Phar
Lap
ETS
支持
< br>)
这套库提供
了对这些对象的访问方法。注意，
RtWinAPI
可以被标准
Win32
环境和
RTSS
环境调用。虽然
在
Win32
环境中使用
R
tWinAPI
不能提供在
RTSS
下
的确定性，
但是却可以允许应用程序在更
加友好的
Win32
编程环境中开发而不是
DDK
环境
[Anschuetz
98]
。将
Win32
程序转化为
RTX
程序只需要重新链接一套不同的库而已。
Windows
XP
服务控制管理器直接将
RTX
进程和动
态链接库
(DLL)
的可执行映像装入内核的不分页内存中。
图
1
RTX
架构
深入
RTX
实时硬件抽象层
(HAL)
HAL
是
Windows XP
系统提供的可被用来进行修改和扩展的资源的一部分。
RTX
修改
HAL
有以下
3<
/p>
个目的：
?在
Windows XP
和
RTX
线程之间增加独立的中断间隔；
?实现高速时钟和定时器；
?实现关闭处理程序。
中断隔离意味着
Windows
XP
线程和
Windows
XP
管理的设备不可能中断
RTSS
，同时
Windows XP
线程也不能屏蔽
RTSS
管理的设备。
HAL
通过控制处理器级的中断屏蔽满足这些
条件。当运行
RTSS
线程时，所有
Windows
XP
控制的中断都被屏蔽掉。当
Windows XP
线程
请求设置中断屏蔽时，
作为实际管理中断屏
蔽的软件，
HAL
确保没有任何
RTS
S
中断被屏蔽。
Windows XP
提供的计时器
的最小计时单位为
1000
微秒
(1<
/p>
毫秒
)
。
RT-
HAL
将其降到了
100
纳秒并且提供
了同步
(
与计时器
)
< br>的时钟。
Windows XP
停止保护
除了中断管理和更快的定时器服务
，实时
HAL
也提供了
Windows
XP
关机管理。当
Windows
XP
正常关机或者蓝屏崩溃时，
RT
SS
应用程序可以被关联到
Windows XP
关机管理
器。正常关机允许
RTSS
不受影响的继续运行，直到所有的
RTSS
关机处理器
返回。但当出现
蓝屏时，
RTSS
关机
处理器就会受到限制，
它将无法调用
Windows XP
的服务
(
例如分配新内存
< br>)
。
在实际中，
这意味着当系统
正常关机或者崩溃时，
关机处理器清除一切并复位硬件，
还可能
向操作者发出警告，或者切换到备用状态。
图
2
：
RTSS
详细
架构
扩展
HAL
自从
RTX4.3
< br>，
一直采用扩展
HAL
的方式而
不是替代。
HAL
扩展驱动在操作系统初始化时
启动
(SERVICE_SYSTEM_START)
，在内存中完成对
HAL
的动态检测、中断截取、定时器和关机
的相关调用，并且重定向到
RTX
的相
应位置。这种二进制钩子技术比起替代
HAL
来有许多
优点：
?
RTX
可
以处理很广泛的
OEM
平台，
这种重定
向调用被限制在一种对于不同的
OEM
和
服务商之间很少区别的调用上。
?
RTX
兼容更大范围的
Windows
XP
补丁包
(Service Pack
，
SP)
，
为了配合最新的
HAL
资源
的补丁包而修改
RTX
是不必要的。
?因为磁盘上的
HAL
未被改动，所以安装变得更加容易，因此
RTX
也不
受
SP
升级的影
响。
< br>
?升级到更新的
Windows
版本变得容易，不费什么力气。
当
RTX
在
Windows
NT
和
Windows
2000
的后续
SP
上不经修
改的成功安装，扩展
HAL
的好处也就无需证明了。
RTX
和中断延迟
软件引起的中断
当
RTX
高速时钟或者其他设备产生
RTX
中断
时，
就会发生从
Windows X
P
到
RTX
的转换。
< br>所以，为达到
RTX
的
ISR<
/p>
的确定性就必须减少
Windows
X
P
的中断延迟。让我们先来考察一
下在没有
RTX
的情况下
Windows XP
平台的
ISR
延迟来源。
最显著的延迟是由
Windows
X
P
内核和驱动引起的
IRQ
屏蔽，一般
是通过
Windows
XP
的
KeRaise/LowerIrql
函数调用在几毫秒内实现的。<
/p>
Windows XP
内核，
HAL
和某些特殊驱动也
通过
x86
STI/CLI
指令集在几微秒内完成处理器级的中断屏蔽。
Windows
XP
和
RTX
中断处理自然会屏蔽中断，所以也肯定会增加
ISR
延迟。虽
然在很
多情况下
Windows
XP
非常依赖于中断处理
(
例如软件异常，
释放线程堆栈
)
，但其中断顺序
依然取
决于最坏情况下的延时。
硬件引起的中断
和硬件有关的最明显的问题就是应用程序和操作系统对高速缓
存的污染和转储清除。
TLB
的重填也属于这种情况。视频驱动
的缓存占有量是极大的，当
RTX
中断启动时会造成竞
争性的转储清除。当应用程序引起缓存污染时，
ISR
< br>的直方图上将出现典型的双驼峰型。大
部分采样靠近最好情况的区域，另外一大部
分靠近存储清除的区域
(
见图
3)
。