减少优先级倒置问题及基于ORBs中间件的非确定性的软件体系结构

 

减少优先级倒置问题及基于ORBs中间件的非确定性的软件体系结构

 

Douglas C. Schmidt          

schmidt@uci.edu fsumedh

电子 & 计算机工程系

加利福尼亚大学欧文分校

 

Sumedh Mungee, Sergio Flores-Gaitan, and Aniruddha Gokhale

{fsumedh,sergio,gokhale}g@cs.wustl.edu

计算机科学系

华盛顿大学圣路易斯分校

 这篇论文于2001年由荷兰出版商Kluwer出版于实时系统刊物的第2期第21卷。

                        抽象

  由于并行分布式应用程序对于实时性的需求，扩展ORB中间件以支持分布式应用程序的呼声越来越高。然而，传统ORB中间件的执行，比如CORBA中间件，对于实时系统对确定性要求，表现出了不适应于此要求的实质性优先级倒置及非确定性。本篇论文为实时系统ORB中间件的研究与设计提供了2种新思路。第1，从以往经验出发，详细举例说明并图解了传统ORB中间件为何无法支持实时系统服务质量的原因。第2，对软件体系结构的连接性及并行性进行了评价，以综合判断实时系统CORBA ORBs中各种减少优先级倒置及非确定性的策略。本篇讨论的观点论证了利用比如CORBA这样的标准面向对象技术的中间件，通过Internet来支持某些特定种类的实时应用程序的可能性。

关键词:实时系统CORBA中间件，面向对象服务质量保障中间件，成效评估

 

1．        介绍

新一代分布式实时应用程序，比如视频会议，航空电子任务计算和过程控制，需要可以提供完善统计数字及具有确定性质量服务的终端系统以保证反应时间[1]，带宽及可靠性[2]。我们以下所讨论的趋势或倾向将改变分布实时应用程序及终端系统软件开发技术的发展。

集中性增强的中间件和综合架构： 目前在实时系统的研究与开发项目中有一种倾向认为，可以使用基于面向对象的中间件[3]的可重用构件来整合应用程序，从而开发一个实时系统的大致模型架构。中间件的目的即是提高系统效率并减少周期和不同供应商为整合可重用构件而所需做的软件开发工作。

集中性增强的服务质量保障中间件和开发系统：具有完善统计数字及确定性质量服务的开放分布式应用程序构件[4]实现了单一化协作过程，所以，对于实现这一协作过程的远程过程调用及通信技术的需求也逐渐增多。随着内容的多种多样，这些构件必须满足应用程序的功能性及质量保障体系的要求。

集中性增强的标准化和符合杠杆作用原理的用于CTOS嵌入式实时多任务操作系统的硬件及软件：为了对降低培训、移植、维护费用而进行的开发起到杠杆作用，对于CTOS硬件和CTOS操作系统的开发速度也提出了更高的要求。一些有关于CTOS的硬件及软件国际标准目前以质量保障体系标准发行。

其中一个特别值得关注的标准化效果是产生了OMG(对象管理组织)的CORBA(公用对象请求代理（调度）程序体系结构)规范[5]。CORBA是这样的一种中间件，它允许客户调用远程对象方法而无须关心对象的具体位置，使用何种语言编写，运行在怎样的操作系统及硬件平台上，以及相互连接分布式对象通信与网络协议种类[6]。

最近标准CORBA在实时系统[7]及嵌入式系统[8]开发领域又取得了新的进展。一些OMG团体，其中的绝大多数对于实时系统具有浓厚的兴趣(RT SIG)，正在为定义CORBA标准的扩展以支持分布式实时应用程序积极的工作。标准化的实时系统CORBA组件的目标在于，使得实时应用程序可以通过嵌入式系统或多种不同的分布式环境相互作用联系起来，比如Internet。

然而，对分布式实时系统ORB中间件的开发、标准化以及使用杠杆原理配置工作依然显的艰难，尽管上述OMG团体(RT SIG)做出了大量卓有成效的工作。广泛展开、并且标准化的分布式实时系统ORB中间件在CTOS操作系统及相关硬件上运行的成功实例是非常少的。传统的CORBA ORBs一般来说并不适合于对性能非常敏感的分布式实时应用程序，主要原因在于它们[1]缺少服务质量保障的借接口规范，[2]缺少服务质量保障的环境，[3]实时系统的规划特性以及[4]严重的性能低下及[9]不可预见性。

尽管目前一些操作系统、网络协议支持实时系统时序安排，可是并没有给出一种完整的端到端解决方案[10]。而且，关于实时ORB终端系统策略的相关研究也非常少见，且并不深入。例如，服务质量(QoS)研究在网络与操作系统层仅仅刚开始涉及关键性需求及为ORB中间件进行建模设计[11]。

从历史观点来看，高速网络的QoS研究，比如ATM，很大程度上将重点放在了分配虚电路带宽上[12]。同样地，实时操作系统的研究则将精力放在了避免

多线程应用程序的同步状态下优先级倒置和分派机制上[13]。所以，一个非常重要的开放性研究课题，是确定怎样最好地将从网络层和操作系统层来的QoS结果部署到许多使用ORB中间件的实时应用程序开发者所熟悉的编程模型上来。

本篇论文以如下方式组织：第2部分勾勒了影响实时ORB终端系统性能及可预见性的基本因素；第3部分描述实时ORB核心的软件体系，焦点集中在可选择性的ORB核心通信与连接软件体系；第4部分代表了一种经验性的观点，系统地测试各种可选择的ORB核心体系的4种不同时期的CORBA执行方法：CORBAplus, miniCOOL, MT-Orbix和TAO；第5部分比较了与我们的研究成果与相关的实践工作；第6部分主要是结束的评论部分，为求尽善尽美，附录A提供了一套完整的CORBA参考样式。

2.影响实时ORB终端系统性能的因素

满足Qos性能需求下一代分布式应用程序所需要的不仅仅是定义一套接口定义语言(IDL)或是在操作系统中加入一套抢先式实时系统时序控制体系。它还需要一套二维网格状完整的ORB终端系统体系，在整个分布式系统的多层次上来发送有QoS担保的端到端信息[10]。在一个ORB终端系统中，关键的层次包括网络适配器，操作系统输入/输出子系统，通信协议，ORB中间件，以及图1所指出的高层次服务。

本篇论文的焦点在于适合于实时ORB核心的软件体系架构。ORB核心是CORBA参考模型中管理传输连接，发送客户请求到对象适配器，并且返回回应(如果需要)到客户端的组件。并且它也执行端点(多路)信号分离器传输和应用程序所使用的通信体系架构。图1举例说明了ORB核心如何与其他ORB组见整合为一体。附录A更加具体地描述了标准CORBA组件。

   

更加完全的，2.1节简要地叙述了基于ORB终端系统的性能原始资料。2.2节描述了影响实时ORB终端系统的可预见性和利用率的优先级倒置和非确定因素的关键原因。在总体概括后，第3节对可选择的ORB核心通信与连接体系进行了深入探讨。

2．1基于ORB终端系统性能的原始资料

我们的测量CORBA实现的吞吐量和延迟的经验[14, 15, 16, 17]表明在实时ORB端系统中的性能开销来源于以下组件的低效：

1．网络连接和网络适配卡：这些组件处理异构网络的连接和带宽，它们能极大地增加延迟和引起性能的变化。网络适配卡的低效设计会引起排队延迟和丢失数据报[18]，对于某些类型的实时系统而言，这些是难以接受的。

2．通信协议的实现和同I/O子系统和网络适配卡的集成：低效的协议实现和同I/O子系统的不适当的集成会逆向影响端系统的性能。引起无效性的特定因素包括由流控制、阻塞控制、重发策略、和连接管理引起的协议开销。同样，缺乏同I/O子系统的适当集成会产生过量的数据拷贝、碎片、重装、上下文切换、同步、检查和计算、多路转发、编组和解组等开销[19]。

3．ORB传输协议的实现：ORB传输协议的低效实现，如IIOP协议[5]和SFP[20]协议，会引起极大的性能开销和优先级颠倒。要对这些颠倒负责的特别因素包括在ORB协议实现中的不适当的连接管理策略、低效的端系统资源共享、和过多的同步开销。

4．ORB核心的实现和同操作系统服务的集成：一个设计不当的ORB核心会产生过多的内存访问、高速缓存命中率低、堆的分配/去分配、和上下文切换[21]。反过来，这些因素会增加延迟和抖动，这对于具有确定的实时需求的分布式应用来说是难以接受的。引起低效的特定ORB核心因素包括：数据拷贝、分割/重装、上下文切换、同步、检查和、socket多路转发、定时器处理、请求多路转发、编组/解组、分帧、错误检查、连接和并发性结构。许多这些低效性与‘2’类似，因为它们都发生在用户级而不是核心级（注：相对于操作系统而言），然而，ORB实现常常能更方便地处理它们。

图2标示出了以上叙述的影响ORB系统性能的多方面因素所在以及如何真正在实用中进行最优化工作以减少优先级倒置和不确定性的关键原因。在页低，我们描述了ORB终端系统中应主要对优先级倒置和非确定因素负责的组件。

2．2 ORB终端系统用中导致优先级倒置与非确定因素的原因

对于控制实时操作系统和ORB中间件的程序执行时间来说，将优先级倒置和非确定因素影响最小化是非常重要的。在ORB端系统中，优先级颠倒和不确定性通常来源于在多个线程或进程之间共用的资源（注：高优先级线程可能因竞争不到资源，而必须等待低优先级的线程释放资源）。常见的可共用ORB端系统中资源包括供一个CORBA IIOP协议引擎使用的[1]TCP连接，用来通过客户和服务器的传输端点传输请求的线程[2]，进程范围的动态内存管理器[3]，以及内部的ORB数据结构[4]，如传输端点的连接表和客户请求的多路分解的映射。以下描述在常规ORB端系统中优先级颠倒和不确定性的关键来源。

2．2．1 操作系统I/0子系统

一个I/O子系统是操作系统中的一个组件，负责居中协调应用程序和ORB对低层的网络资源和操作系统资源的访问（注：应用程序和ORB是一方，操作系统和网络是另一方，I/O子系统是居中协调者），这些资源包括设备驱动程序、协议栈、CPUs等。在创建一个高性能、实时I/O子系统中的关键挑战在于[1]要最小化上下文切换（如挂起一个线程转去执行另一个线程引起的上下文切换）和同步的开销，[2]要实施QoS保证，而同时要最小化优先级颠倒和不确定性。

当一个正在执行的线程自愿或不自愿地放弃正在执行它的CPU时，就会触发（发生）一个上下文切换，依赖于下层的操作系统和硬件平台，一个上下文切换可能需要执行数百条指令来刷新寄存器窗口、刷新内存高速缓存、刷新指令流水线、和刷新转换旁看的缓冲区。同步的开销来自于封锁机制，这些机制串行化对共享资源的访问，典型的共享资源如在操作系统和ORB中I/O缓冲区、消息队列、协议连接记录、以及在协议处理期间使用的多路转发映射。

诸如Solaris 和 Windows NT等通用操作系统的I/O子系统不执行抢先的、按优先级的协议处理。因此，较低优先级的数据报的协议处理是不会由于较高优先级的数据报的到达而被延迟的，而是进入的数据报按它们到达的顺序被处理，不是按它们的优先级被处理。

                

[22]检查了在I/O子系统中引起的关键优先级颠倒问题，并描述了TAO的实时I/O子系统如何通过协同调度用户级和核心级实时线程避免许多形式的优先级颠倒问题。有趣的是，在第四节中的结果表明，在ORB端系统中的多数开销、优先级颠倒、和非确定性并不起源于在I/O子系统中协议实现，而是来自ORB核心的软件结构。

2．2 ORB核心

一个ORB的核心是CORBA中的一个组件，它实现通用ORB间协议（GIOP），该协议定义了（可以是异构的）ORB间互操作的格式。ORB核心建立连接和实现处理GIOP请求的并发性结构。以下的讨论描述了在通常的ORB核心实现中的优先级颠倒和非确定性的根源。

连接结构：ORB核心的连接结构，定义了请求如何被映射到网络连接，对ORB实时系统的表现起到主要影响。因此，对于实时ORB的开发人员的一个关键挑战是要选择一个能有效地利用一个ORB端系统的传输机制的连接结构。以下讨论描述了由通常ORB核心的连接机制展现的优先级颠倒和非确定性的根源：

l        动态连接管理：通常的ORB以响应客户请求的方式动态地建立连接。然而，动态连接管理可引起极大的运行时的开销和优先级颠倒。例如，一个高优先级的客户可能要等待一个低优先级客户完成连接建立，而且，建立连接所需的时间可能变化很大，范围从微秒级到毫秒级，取决于端系统的负载和网络的拥挤程度。

        连接建立的开销是很难定界限的，例如，如果ORB需要动态地在一个客户和一个服务器之间建立连接，是难以提供一个最坏情况下执行时间的合理保证的，因为这一时间必须包含（常常是变化的）连接建立时间。而且，连接建立常常会发生在通常的端对端操作系统QoS协议实施机制的范围之外，例如重发计时器[25]。为了支持应用的确定性的实时QoS需求，因此ORB端系统常常必须事先预分配连接。

l        连接的多路复用：通常ORB核心常常由一个服务进程内的伺服程序的所有对象引用共用一个单一的多路复用的TCP连接，见图3。

       连接多路复用的目的是要最小化每个服务器打开的连接的数量，例如要改进服务器在TCP上的可扩放性。然而，连接的多路复用回产生极大的数据报级的优先级颠倒和同步的开销，见后面的章节。

并发性的结构：ORB核心的并发性的结构（它定义如何将请求映射到线程）也对它的实时行为有极大的影响。实时ORB的开发人员面临的另一个关键挑战是要选择能有效地在一个或多个线程中共享一个ORB端系统和它的应用操作的总的处理能力的一个并发性体系结构。以下描述由通常的ORB核心的并发性机制展示的优先级颠倒和非确定性的关键根源：

l        双向的操作响应处理：在客户方，双向操作的通常ORB核心的并发性结构可能会引起极大的优先级颠倒。例如，使用连接多路复用的多线程ORB核心在正在等待一个服务器的副本的低优先级线程封锁住正在等待同一服务器的副本的较高优先级的线程时，就会引起优先级颠倒。

l        线程池：在服务器方，ORB核心的并发性结构常常使用线程池[26]来选择一个处理一个进入的请求的线程。然而，通常的ORB不提供使实时应用能指派这一池中线程的优先级的程序设计接口。因此，池中一个线程的优先级常常不适合于将最终执行该请求的伺服程序的优先级。一个设计不当的ORB核心会增加优先级颠倒和不确定性的可能性和持续时间[27]。

2．2．3 对象适配器

对象适配器是CORBA体系中负责分接请求，以服务于响应对应请求的操作的组件。一个标准的适应于GIOP的客户请求包含了其对象与操作的身份识别。每个对象被一个8个字节的对象标志所识别，当然对象标志是唯一的。每个操作被表示为一组字符串。如图4所示，ORB终端系统必须负起以下分接的任务。

步骤1与2：从网络物理层开始，通过数据链路层，和传输层到应用层分界（例如:接口套），这里数据在一个服务器进程里被传输给ORB核心，这个过程中操作系统的协议栈分时地分接客户的请求信息      

步骤3与4：ORB核心在客户对象标识上使用地址信息来定位适当的POA接口和服务。POA接口被分层次的组织。因此，定位指定服务的POA可以使我们专注于嵌套的POA分层中的一系列分接步骤。

步骤5与6：POA接口使用方法名称来定位适当的IDL框架，这个框架对方法参数的请求缓冲进行反编列并执行内核线程upcall来对开发者工作进行补充编码，以执行对象的方法。

 如图4所示的传统深层的ORB终端系统总体来说并不适合对性能要求较高的实时系统，原因如下所述[28]：

逐渐减少的效率：在ORB终端系统处理过程中，分层的分接产生了额外的必须以客户需求递增被搜索的内部表格，因而降低了性能。在所有这些层次中分接客户请求是非常昂贵，尤其是当很大一部分的操作同时集中出现在一个IDL接口中时，或者说很多的服务被一个对象适配器所管理时。

逐渐增长的优先级倒置与非确定性： 由于对于低层的设备驱动和ORB终端的I/O子系统协议栈来说，服务层Qos信息是无法取得的，所以分层解复用会导致优先级的倒置。因此，一个对象适配器也许会根据他们获取的FIFO次序解复用数据包。FIFO解复用将会导致更高优先级的信息包却要在不确定的时间里等待低优先级的信息包被解复用和分派出去。

传统的CORBA执行方式将导致严重的提前解复用问题.举例来说, [15, 17]表现出传统的ORBs有17%的服务器时间来处理解复用请求,除非提前问题能够被降低并且解复用能够表现出可预见性。对于实时系统,ORBs无法作出统一,且可升级的Qos保证。

[14]现在可选择性的ORB解复用技术描述了Tao实时对象适配器如何提供最理想的解复用策略来持续稳定的执行。Tao使用的解复用策略采用可以根据Tao适配器来移除不必要层次的未分层解复用来避免优先级倒置。

 

3       选择性的ORB核心通信及连接体系架构

在这一部分描述了相当数量的普通ORB核心通信和连接体系架构。每种体系可以被一种或多种的用于商用及研究的CORBA所执行。下面，我们从质量上评价一下每种体系是如何管理ORB终端组件的集合处理能力和应用程序操作。第4部分从数量上举例说明了实际应用中这些可选的表现有多么高效率并具有可预见性。

3．1 可选择的ORB核心连接体系

有二个构造一个ORB核心的连接结构的通用策略：多路复用和非多路复用。集中于客户端连接架构，我们对下面的各种各样的设计选择情况分别作出描述和评价。

   3．1．1 分解体系架构

    大多数传统的ORBs 分解所有从与一个进程进行的连接中发散出的所有客户端请求。这一多路复用的连接结构通过最小化被打开通向每个服务器的TCP连接的数量被用来构建可扩放的ORBs。然而当使用多路复用时，一个关键挑战是要设计一个有效的支持并发的read 和 write操作的ORB核心的连接结构。

TCP提供了无类型的TCP提供了无类型的字节流数据传输语义。因此，多个线程不能自同一个socket并发地进行read和write, 同样，对在一个ORB进程内共享的一个socket的写操作必须被串行化，串行化通常是通过一个客户进程在写一个共享socket之前先要得到一个锁这样的方式来实现的。

 对于单路操作，当一个请求发出后，并没有必要来设置额外的锁方式或者进程。而对于共享信息的双路复用来说，情况就变得要复杂起来。然而，在这种情况下，ORB核心必须允许多线程协作式的对socket终端进行’read’操作。

如果服务器的应答通过一个单一的TCP连接被多路复用，则多个线程不能同时从哪个socket端点进行读，而是ORB核心必须通过使用同原来的客户请求一起发送和同该伺服程序的应答一起返回的GIOP序列号，多路转发进入的应答到适当的客户线程。

有几种常用的方法来实现连接的多路复用，以允许并发的read 和 write，描述如下：

主动的连接结构：

l        回顾：其中的一种策略是使用图5所示的活动体系架构。一个应用程序线程调用一个双路复用，使得request进入ORB的队列。

(1) ORB核心中有一个独立的线程为这个队列服务。

(2) 并且在众多socket中由ORB线程选择的一个socket上执行write操作。

    ORB线程选择的一个socket：一个客户端可能与许多的服务器存在着许多socket连接。                        

(3) 该ORB线程在这一socket 上执行select操作，等待服务器的应答。

(4) 并且将回复加入一个消息队列。

(5) 最后，应用程序线程重新得到队列的回复消息。

(6) 并将其发回给请求者。

 

l        优势

主动连接结构的优点在于它通过使用一个相同的排队机制简化了ORB的实现。此外，如果每个socket处理相同优先级的数据报，即不会在同一socket上接收到不同优先级的数据报，主动连接能以先进先出的次序处理这些数据报不会引起请求级的优先级倒置[22]。

l        缺陷

    这一结构的缺点是主动连接促使在涉及双向操作时促使额外的上下文切换。因此，为了最小化这一开销，许多ORBs使用主动连接结构的一个变体，描述如下。

 

领导者/跟随者连接体系 

(1).回顾   可替代活动体系架构的另一种模型是如图6所示的领导者/跟随者连接体系。与以往一样，一个应用程序线程调用一个双路复用

(1). 不是将请求排在一个ORB消息队列中，而是直接经socket发送该请求。

(2).