tao-architecture.htm

ACE详细介 绍ACE详细介绍译文.pdf译文.pdf绍译文.pdf

<IMG SRC="i/corba_demux2.gif">
</center>
<tr><td align=center>
图 4. 分层和DE分层的多路分解
</table></center>
<p>

通过所有层的多路分解客户请求的代价是非常昂贵的,
尤其是当在一个IDL接口中存在大量的操作或者是一个ORB管理着大量的对象更表现的如此.为了减少开销,
TAO使用de-分层多路分解 (Figure 4(B)).这种近似使用多路分解键(demultiplexing keys)的方式把ORB指派给客户端.
这些键映射客户请求到对象/操作在O(1)时间里不需要任何的哈西运算或搜索. <P>

为了将来减少多路分解层的数目,APIC能通过编程和使用ATM虚拟环路的方式直接分发客户请求.
这种策略减少了多路分解的执行时间和支持在每请求或每对象基础上的端对端QoS.<P>

<HR><P>
<H4><A NAME="ridl">4. 通过实时IDL模式实现QoS规范</a></H4>

使用TAO的实时应用程序必须明确指定它们要调度的资源请求所需要的TAO的<A HREF="PDF/TAO.pdf">实时调度服务</A>.
在程序执行前，一个基于每操作的QoS信息在程序执行前提供给TAO.为了CPU的需要, 通过
<TT>RT_Operation</TT>s使用<TT>RT_Info</TT>中的IDL<TT>struct</TT>属性来表示Qos需求 图 5. <P>

<center><table cellpadding=1 border=4 cellspacing=4>
<tr><td>
<center>
<IMG SRC="i/program_model.gif">
</center>
<tr><td align=center>
图 5. TAO的QoS规范模型
</table></center>
<p>

<TT>RT_Operation</TT>是一个调度操作, <EM>i.e.</EM>,它通过TAO使用<TT>RT_Info</TT> <TT>struct</TT>表示成一种被调度的资源需求
.<TT>RT_Info</TT>属性包含了worst-case执行时间周期,
重要的和数据依赖的.使用与RMS和RMA分析方法类似的调度技术,TAO实时调度服务判断在一个应用中是否有一个基于所有<TT>RT_Info</TT>数据的知识为所有的<TT>RT_Operations</TT>的可行度量. <P>

这些属性对于通过使用TAO来 (1) 验证调度的可行性和 (2) 定位ORB系统和网络资源是足够的.
目前,开发者必须通过CORBA接口手工来确定这些参数并将它们提供给TAO的<A
HREF="#schedservice">实时调度服务</A>.我们应计划通过创建一个监视examples脚本执行的工具来自动取出这些必要的实时参数.同样,作为真实执行的替代,仿真结果能被
用来为每个操作定义<TT>RT_Info</TT>属性. <P>

<HR><P>

<H4><A NAME="schedservice">5. 实时调度服务</a></H4>

TAO的实时调度服务是一个CORBA对象，它具有以下的离线和运行时职责:<P>

<UL>
<LI> <B>离线可行性调度分析</B> -- 它以调度服务的<TT>RT_Info</TT>仓库方式处理
离线可行性调度分析的IDL操作注册用以检测CPU的资源是否足够用于请求任务的处理. <P>

<LI> <B>线程优先级的指派 </B> -- 在离线分析的过程中,调度服务指派线程的优先级.在运行时,调度服务提供一个接口允许TAO的ORB核心能访问这些优先级
这是它们以操作系统级分发器的形式为接口提供的机制. <P>

<LI> <B>协同模式的改变 </B> -- 在运行时,调度服务协同模式的改变. <P>
</UL>

TAO运行时调度模式的参与者显示在<A
NAME="schedulingfig">图 6</A>中并描述如下: <P>

<center><table cellpadding=1 border=4 cellspacing=4>
<tr><td>
<center>
<IMG SRC="i/os_dispatcher-light1.gif">
</center>
<tr><td align=center>
图 6. TAO的调度服务
</table></center>
<p>

<ul>
  <li><strong><em>工作任务</em></strong> -- 一个<CODE>Work_Task</CODE>
      是一个工作单元它概括了应用级的处理和通信活动.在一些MDA项目中,一个工作任务也被称为一个
       <em>模型</em> 或者 <em>过程</em>, 但是我们避免这些术语因为它们过多使用.<p>

  <li><strong><em>RT_Task</em></strong> -- 一个<CODE>RT_Task</CODE>是一个具有时间约束的工作任务.  每个 <code>RT_Task</CODE> 被认为
  是一种在它们<EM>运行时信息</EM> (<CODE>RT_Info</CODE>)描述的属性条目中拥有自己特殊的QoS信息的``方法'' (函数). 因此, 
  一个具有多个方法的应用级对象可能需要多个<CODE>RT_Task</CODE>实例. <P>

  <li><strong><em>线程</em></strong> -- 合作的一组单元.
       相关的线程, <em>有：</em>, 一个Solaris或POSIX
       线程, 一个Ada的任务, 一个VxWorks任务, 或一个Win32线程. 所有的线程被包含在<code>RT_Task</code>s中; 一个
       <code>RT_Task</code> 能包含零个或多个线程. 一个
       <code>RT_Task</code> 却不能包含任何只能在另一个<code>RT_Task</code>上下文中运行的线程, <EM>i.e.</EM>, 它必须``借用'' 另一个
       控制运行的任务线程(<EM>e.g.</EM>, 对象适配器的) .<p>

  <li><strong><em>操作系统分发器</em></strong> -- 操作系统分发器使用线程优先级选择下一个运行的线程并将它指派给一个CPU. 
   当线程被阻塞(即它不能继续运行)或被另一个优先级更高的线程<em>抢占</em>时，操作系统分发器将这个线程从CPU移出.
   在<em>抢占的分发中</em></a>, 任何优先级高的线程将取代优先级低的线程序.在这个时候优先级高的，运行的线程序被分发到CPU上.<p>

       在我们基于RMA的分析中,假设<em>固定的优先级</em>(fixed priority),
       <em>i.e.</em>, 操作系统不能改变线程的优先级别. 对比这些以时间共享的操作系统调度,典型的是通过降低它们在时间上的优先级而进行<em>age</em>长时间的处理.  因此,从那时的操作系统分发器的视图来看, 每个线程的优先级是不变的.<p>

  <li><b><i>RT_Info</i></b> -- 一个<code>RT_Info</code>结构明确讲是一个<code>RT_Task</code>的调度特性集(比如计算时间和运行周期).  <P>

  <li><b><i>实时调度器</i></b> -- 在运行时, 调度服务最重要的部分是实时调度器.  实时调度器在系统中为每个<code>RT_Task</code>管理一个<code>RT_Info</code>
   结构.  在使用<code>RT_Info</code>中的一个<code>RT_Task</code>时
       , 实时调度器能为<CODE>RT_Task</CODE>的调度特性提供查询 (e.g., 一个任务的优先级) .  当前,在<code>RT_Info</code>结构中的数据代表是离线计算的, <EM>i.e.</EM>, 
       优先级是静止赋予更早的运行时间.<p>

</UL>

<HR><P>

<H4><A NAME="presentation">6. 构件和最优化的表现层</A></H4>

表现层在一个高性能的通信系统中是个大的瓶颈.这层转换从高级表现到低级表现的操作参数(即编组)反之(解组).  
在TAO中,这些转换操作是通过高效的IDL编译器生成的客户桩和服务器框架完成的.
这些杂TAO表现层的优化操作的实现描述如下.<P>

<B>6.1. 表现层的优化</B><P>

这种在IDL定义和目标编程语言之间的转换是通过TAO的IDL编译器自动完成的. 此外减少了客户桩和服务器框架之间潜在的不一致性, 
编译器支持自动更新优化.
TAO IDL编译器被设计成可为IDL类型的编码、解码生成和配置多种策略.  举例,
基于一种运行时应用类型的测量, TAO 既能连接编译，也能解释IDL桩和骨架.  这样一种灵活性能在解释模式(运行速度慢一些，但尺寸会更小一些)和编译模式(速度会更快，但尺寸会大一些)
之前获得一种最佳的平衡点.<P>

同样, TAO 能缓冲那些要反复使用的预编组的应用数据单元(ADUs)
.  当ADUs在``请求链''被顺序传递时和and 每个ADU在从一处传递到另一处时的细微改变 能提高性能.  在下面的案例中, 在每一次的
整个过程中，ADUs是不必编组的. 最优化要求实时ORB执行应用程序代码的流分析以确定请求字段能否被缓冲. <P>

虽然这些技术在一般情况能相当程度减少编组过载
, 有严格实时服务要求的应用程序经常要考虑只有最坏情况的执行.  这样的结果是,
流分析的最优化描述只能使用在确定环境上, e.g., 目的是让应用程序能接收、统计实时服务的或当最坏情况for applications that can
accept statistical real-time service or when the worst-case scenarios
are still 足够to meet deadlines. <P>

<B><A NAME="memory">6.2. 内存优化管理</b><P>

通常CORBA工具经常忍受过多的动态存储管理和数据拷贝.  因为
堆栈的分段存储能为不同的消息大小和不同的工作量表现出不均匀的性能的原因动态存储管理会是硬盘实时系统的问题.
同样, 在整个ORB端系统中过多的数据拷贝会很大程度上降低端到端的性能. <P>

现存的ORBs为多处理器使用动态存储管理.  ORB核心通常为每个接收到的客户请求分配存储空间.  IIOP解组引擎
通常为保持的解码请求参数分配存储空间.  最终, IDL 分别在上调之前和上调之后动态分配和删除客户端请求时参数的拷贝.<P>

这些存储管理策略在一些环境中非常重要(e.g., 当上调生成用于修改它们输入的线程应用时为了防止破坏内部CORBA缓冲区).
然而, 这种策略不需要为实时应用增加内存和总线负载, 和流媒体应用一样(比如 卫星监视和电视会议)
在消耗它们输入而不用立即修改它.<P>

TAO 被设计为小型化和清除在多点的数据拷贝.  举个例子, TAO的 ``零拷贝'' 缓冲区管理系统
被描述在允许客户请求被发送和接收和从不会导致任何数据拷贝开销的网络来.
此外, 这些缓冲区能在ORB的不同传输阶段被重新分配和传递.  另外, 集成层处理(ILP) 能用户减少数据的移动.  因为 ILP
需要维护顺序的约束, 我们提供的编译器技术(比如 控制和数据流分析) 用于检测ILP能被有效用于哪些方面. <P>

将编译器技术用于表现层和存储管理功能允许我们在不修改标准OMG IDL和CORBA应用程序的情况下优化性能. <P>
	
<HR><P>
Back to the <A HREF="TAO-intro.html">TAO intro</A> page.


<P>
<!--<EM>
Visitor #
from 
<EM><br> -->
<I> Last modified 09:10:05 CDT 23 June 2002 </I>

</BODY> 
</HTML>