实时操作系统的一个特点就是，一个实时任务，会在规定的时间内得到响应，并且在规定的时间内完成任务。所以，一切不可预知的动作都是有害的。

有兴趣可以看看下面两个链接：
http://en.wikipedia.org/wiki/Priority_inversion

Priority inversion

From Wikipedia, the free encyclopedia

Jump to: navigation, search

In scheduling, priority inversion is the scenario where a low priority task holds a shared resource that is required by a high priority task. This causes the execution of the high priority task to be blocked until the low priority task has released the resource, effectively "inverting" the relative priorities of the two tasks. If some other medium priority task, one that does not depend on the shared resource, attempts to run in the interim, it will take precedence over both the low priority task and the high priority task.

In some cases, priority inversion can occur without causing immediate harm—the delayed execution of the high priority task goes unnoticed, and eventually the low priority task releases the shared resource. However, there are also many situations in which priority inversion can cause serious problems. If the high priority task is left starved of the resources, it might lead to a system malfunction or the triggering of pre-defined corrective measures, such as a watch dog timer resetting the entire system. The trouble experienced by the Mars lander "Mars Pathfinder"^[1][2] is a classic example of problems caused by priority inversion in realtime systems.

Priority inversion can also reduce the perceived performance of the system. Low priority tasks usually have a low priority because it is not important for them to finish promptly (for example, they might be a batch job or another non-interactive activity). Similarly, a high priority task has a high priority because it is more likely to be subject to strict time constraints—it may be providing data to an interactive user, or acting subject to realtime response guarantees. Because priority inversion results in the execution of the low priority task blocking the high priority task, it can lead to reduced system responsiveness, or even the violation of response time guarantees.

A similar problem called deadline interchange can occur within Earliest Deadline First Scheduling (EDF).

Contents

• 1 Solutions
• 2 See also
• 3 Notes
• 4 References
• 5 External links

[edit] Solutions

The existence of this problem has been known since the 1970s, but there is no fool-proof method to predict the situation. There are however many existing solutions, of which the most common ones are:

Disabling all interrupts to protect critical sections

When disabled interrupts are used to prevent priority inversion, there are only two priorities: preemptible, and interrupts disabled. With no third priority, inversion is impossible. Since there's only one piece of lock data (the interrupt-enable bit), misordering locking is impossible, and so deadlocks cannot occur. Since the critical regions always run to completion, hangs do not occur. Note that this only works if all interrupts are disabled. If only a particular hardware device's interrupt is disabled, priority inversion is reintroduced by the hardware's prioritization of interrupts. A simple variation, "single shared-flag locking" is used on some systems with multiple CPUs. This scheme provides a single flag in shared memory that is used by all CPUs to lock all inter-processor critical sections with a busy-wait. Interprocessor communications are expensive and slow on most multiple CPU systems. Therefore, most such systems are designed to minimize shared resources. As a result, this scheme actually works well on many practical systems. These methods are widely used in simple embedded systems, where they are prized for their reliability, simplicity and low resource use. These schemes also require clever programming to keep the critical sections very brief, under 100 microseconds in practical systems. Many software engineers consider them impractical in general-purpose computers.

Arguably, these methods are similar to priority ceilings.

A priority ceiling

With priority ceilings, the shared mutex process (that runs the operating system code) has a characteristic (high) priority of its own, which is assigned to the task locking the mutex. This works well, provided the other high priority task(s) that try to access the mutex does not have a priority higher than the ceiling priority.

Priority inheritance

Under the policy of priority inheritance, whenever a high priority task has to wait for some resource shared with an executing low priority task, the low priority task is assigned the priority of the highest waiting priority task for the duration of its own use of the shared resource, thus keeping medium priority tasks from pre-empting the (originally) low priority task, and thereby effectively the waiting high priority task as well.

[edit] See also

• Starvation
• Pre-emotive multitasking
• Non-blocking synchronization
• Read-copy-update
• Priority inheritance
• Priority ceiling
• Nice (Unix)

[edit] Notes

1. ^ What Really Happened on Mars by Glenn Reeves of the JPL Pathfinder team
2. ^ Explanation of priority inversion problem experienced by Mars Pathfinder

[edit] References

• "Experience with Processes and Monitors in Mesa" by Butler W. Lampson and David D. Redell, CACM 23(2):105-117 (Feb 1980) - One of the first (if not the) first papers to point out the priority inversion problem. Also suggested disabling interrupts and the priority ceiling protocol as solutions, noting that the former of these two cannot not tolerate page faults while in use.

[edit] External links

• Description from FOLDOC
• Citations from CiteSeer
• IEEE Priority Inheritance Paper by Sha, Rajkumar, Lehoczky

Retrieved from "http://en.wikipedia.org/wiki/Priority_inversion"

 .硬件要求：
    - CPU： Intel X86 P3 500 MHz或更快
    - 内存：512MB (更多内存可以提高编译速度)
    - 硬盘空间： 256MB交互空间+ 250MB至数GB空闲空间（取瘊于您要有
      多少需要构建)

 .操作系统要求：
    - Windows 2000, 2003,或XP  (其实Vista下我试过也可以)
 
 
 .C++编译器要求：
  - Microsoft Visual C++ 6.0 SP5 (新版本的ACE+TAO已不支持VC6了)
  - Microsoft Visual C++ 7.1 (VS2003)
  - Microsoft Visual C++ 8.0 (VS2005)
  - Microsoft Visaul C++ 9.0 (VS2008)

 .其他软件要求：
  - WinZIP或类似的解压缩工具
  - ActiveState Perl v5.6.1或更新版本（推荐，不是必需）

 获取和安装ACE+TAO
  1. 从下载OCI TAO 1.5a的最新补丁
     http://download.ociweb.com/TAO-1.5a/ACE+TAO-1.5a_with_latest_patches.zip
    或从ACE+TAO的官方网站上下载最新Beta版
     http://download.dre.vanderbilt.edu/
  2. 把上述压缩文件释入至没有空格的目录中（例如：C:\ACE_wrappers)
  3. 设置环境变量 ACE_ROOT,TAO_ROOT和PATH.
     例如：如果ACE+TAO安装至C:\ACE_wrappers,则上述环境变量如下：
     * ACE_ROOT=C:\ACE_wrappers
     * TAO_ROOT=%ACE_ROOT%\TAO
     * PATH路径需要包含: %ACE_ROOT%\bin;%ACE_ROOT%\lib
  4. 在 %ACE_ROOT%\ace 目录中config.h文件，文件内容是：
     #define ACE_DISABLE_WIN32_ERROR_WINDOWS
     #define ACE_HAS_STANDARD_CPP_LIBRARY 1
     #define ACE_DISABLE_WIN32_INCREASE_PRIORITY
     #include "ACE/config-win32.h"
  5. %TAO_ROOT%\TAOACE.sln
      在ACETAO工作区(workspace)中的项目构建ACE和TAO库，TAO_IDL编译器、gperf,
      ORB服务库和可执行文件以及一些公共的实用工具(utilities)。他们不包含
      示例、测试和性能测试。库文件将安装至%ACE_ROOT%\lib，一些可执行文件将安装
     至%ACE_ROOT%\bin中，其他（ORB服务的可执行文件）将安装在他们自己的源代码所在
     目录中。
 
     如果您不想全部建议TAOACE workspace的库和可执行文件，我们建议构建Naming_Service
     项目。在开发自己的应用程序里常会用到它。

     如果上述的workspace文件不存在，那么你需要用MakeProjectCreator (MPC)来生成它。
     命令行如下（需要Perl，上面已列出）：
     cd %TAO_ROOT%
     %ACE_ROOT%\bin\mwc.pl -type vc71 TAOACE.mwc -- 成生visual stuido 2003 workspace文件
     %ACE_ROOT%\bin\mwc.pl -type vc8 TAOACE.mwc  -- 成生visual stuido 2005 workspace文件
     %ACE_ROOT%\bin\mwc.pl -type vc9 TAOACE.mwc  -- 成生visual stuido 2008 workspace文件

使用vs2005(vc8)编译log4cpp-0.3.5rc3

ACE/TAO的实现语言是C和C++。用ACE/TAO构建服务器和客户端的过程超出了本指南的范围，但有几个概念还是值得重提：
1. 接口(Interface)定义在OMG 标准的.idl文件中。用TAO_IDL实用程序,TAO可以自动通过.idl文件生成C++的静态存根(stubs)和框架(skeletions),二者分别用于服务器端和客户端.
2.程序员实现在生成的I.cpp静态存根中的接口，再使用惯用的CORBA技术来编写客户端和服务端的代码来进行实现。
3. ACE/TAO提供了一个make实用程序，这个实用程序可以跨平台的管理项目的创建和编译。程序员编写的.mpc文件，定义了所创建的项目所需的源代码，Perl语言脚本创建makefile文件或Visual Sutdio的解决方案。在Linux上，可以生成GC++项目，命令是 mwc.pl -type gcace。在Windows上，产生Visual studio.net 2003解决方案的命令是:mwc.pl -type VC71

Stone Jiang

ACE_Acceptor框架使对新连接的侦听变得容易，也使创建和激活新连接的ACE_Svc_Handler的派生类变得容易。之前我们已经了解了ACE_Svc_Handle::open()挂勾函数和服务处理器

初始化时它所扮演的角色。本文我们回退几步，来了解服务处理器是如何实例化的以及我们如何自定义它的行为。

再看看ACE_Acceptor类，它是一个模板类，第一个模板参数ACE_Accetpor是代表与服务建立连接的处理器。当新的连接建立时，ACE_Acceptor调用make_svc_handler()挂勾函数来

实际创建的新建服务处理器对象。ACE_Acceptor::make_svc_handler()的实现如下:

默认的实现包括了两步基本操作：
1.  获得一个新的SVC_HANLDER对象， 这里是使用的new运算符分配的。
2.  设置新的服务处理器的reactor指针为ACE_Accetpor使用的reactor的。

然而，如果应用程序需要通过其它方式获得SVC_HANDLER对象，而不是通过默认的构造函数那种动态分配，这又该怎么办呢？举例来说，我们可能需要：
 . 从一个预分配的池中获得SVC_HANDLER对象；
 . 为新创建的SVC_HANDLER传入一些额外的信息
 . 使用单体的SVC_HANDLER

上面这些情形，我们都可以自定义make_svc_handler()挂勾函数来实现必要的行为。例如,假定我们新的处理器需要拥有一个处理所有对所有接收到的消息进行集中处理的中心处理

器。这个中心处理器我们用类Processor表示。我们需要每个服务处理器都拥有一个指向中心处理器的指针，而不是使Processor成为一个全局访问的指针(使用全局变量的种种弊端

本文不作详述)。我们的解决办法是: 从ACE_Accetor派生一个新类，这个新类拥有Processor的指针作成员，并且，在创建新和服务处理器(Service)的时候，把这个 Processor的

指针作参数传进去。

新的acceptor类可以这样定义：

class  My_Acceptor :  public  ACE_Acceptor < Service, ACE_SOCK_ACCEPTOR >
... {
public :
  My_Acceptor (Processor  * processor) : processor_ (processor)  ... { } ;
  
   int  make_svc_handler (Service  *& sh)
     ... {
       if  (sh  ==   0 )
        ACE_NEW_RETURN (sh,
                        Service ( this -> processor_),
                         - 1 );       //  Set the reactor of the newly created <SVC_HANDLER> to the same
       //   reactor that this <ACE_Acceptor> is using.
      sh -> reactor ( this -> reactor ());
       return   0 ;
    }

private :
  Processor  * processor_;
}

就这样，现在，当My_Acceptor接受新连接的时候，make_svc_handler()挂勾函数分配一个新的处理器(Service)，并把Processor*作为参数传进去。需要注意的事，尽管这里使用

的是这一个构造函数Service(Processor*)。我们仍需求为Service类定义默认的构造函数，以满足模板类ACE_Acceptor的需要。

Stone Jiang

上一篇我们看了ACE_Svc_Handler::open()挂勾函数提供默认行为的一些技巧。因为在大多数情况下，它完成了服务创建时所需的所有事情：为输入事件注册新处理器和返回。

在ACE_Svc_Handler中关闭操作的默认行为要比在open()中初始化的代码更为复杂。这是因为关闭时的挂勾函数包含了反应式(reactive)关闭和主动式(active-object)关闭两种情

况，它们有相同的效果:删除所有在反应器注册的事件和确保删除ACE_Svc_handler的派生类的对象。

反应式关闭(handle_close()): 当以下形况发生时被调用：
 1) 事件回调函数(译注：handle_xxxx())返回-1时，或
 2) 调用ACE_Reactor::remove_handler()，传入的标记不含 DONT_CALL时
 反应器框架将调用handle_close()挂勾函数。 ACE_Svc_handler::handle_close()的默认行为是调用ACE_Svc_Handler::destroy()销毁事件处理器。

主动对象式关闭(close()): 当ACE_Svc_Handler 派生的对象通过activate()函数转变为主动对象，处理器的的svc()方法在它产生的线程中运行后进行回调。当svc()返回时，线程

退出，但在它要退出时，仍在将要退出线程的上下文中，ACE_Task框架调用它的close()方法。ACE_Svc_Handler::close()方法调用handle_close()完成服务处理器的清理工作。

因此，不管ACE_Svc_Handler对象是反应式还是主动式，结束时的清理工作都在相同的地方：ACE_Svc_Handler::destroy()。如果对象是动态分配且不是ACE_Stream框架中的组成部

分，destroy()将删除此对象，如果对象不是动态分配的，析构它的责任是创建时对象所在的封闭范围。如果对象是ACE_Stream的模块的组成部分，流和/或控制流的代码负责管理

对象的生命期。destroy()函数应遵守这样的规则来避免出现资源泄漏。

无论ACE_Svc_Handler对象是反应式销毁还是主动式销毁，都会引起相同的事情发生：~ACE_Svc_Handler() (处理器的析构函数)调用ACE_Svc_Handler::shutdown()函数完成服务处

理器的清理工作。shutdown()执行的这些清理操作是：

如果处理器与反应器是关联的：
   取消处理器关联的所有定时器。
   为处理器的流对象（如socket)删除所有已注册的事件。
如果处理器与再生器(recycler)是关系的，从再生器中清除处理器。
关闭流对象。
因此，我们看到的绝大多数情况服务处理器通过shutdown需要通过框架来清理工作，都是简单的允许缺省的挂勾函数得以被调用。如果你的应用程序需求更多的关闭/清理规则，推

荐的地方是你的处理器的handle_close()挂勾方法。仅仅是确保把ACE_Svc_Handler::destroy()函数人作为你的handle_close()的最后一个动作，与框架清理行为的余下的行为合

并。

				
						

						
Stone Jiang
ACE_Svc_Handler经常用于网络服务类的基类，这是因为它很容易在主动对象(Active Ojbect)
模式和反应器(Reactor)框架中使用。APG第7.6节中讨论了怎么在接受器-连接器(Acceptor-conector)
框架中如何把ACE_Svc_Handler作为目标来使用，并且，在C++NPv2第7章中，深度探讨了
Acceotor-Connector的相关设计。
挂勾函数(Hook method)ACE_Svc_Handler::open()常是服务中新建连接时执行的初始化设置的地方。
举例来说，如果服务要在日志中记录新连接建立的相关信息，open()函数是则是记录这个信息的地方。
对于使用Reacotor 框架的服务检查网络数据到达，open()是执行reactor注册的地方。
事实上，这正是reactor注册的地方，这种动作在服务建立新连接时非常常见的，ACE_Svc_Handler::
open()的缺省操作也正是
if (this->reactor () && this->reactor ()->register_handler
          (this,
           ACE_Event_Handler::READ_MASK) == -1)
  ACE_ERROR_RETURN ((LM_ERROR,
                     ACE_LIB_TEXT ("%p\n"),
                     ACE_LIB_TEXT ("unable to register client handler")),
                    -1);
return 0;
所以，如果在与服务建立新连接并为“读事件”注册时，你甚至不需要在你的类中
实现open(void*)函数，ACE已经为你做了这一步!另外，请记住，如果reactor注册失败，
默认的open()函数会返回-1，它会引起Acceptor-Connector框架关闭新建的连接和删除这个
事件处理器(handler)。
Stone Jiang
http://www.cppblog.com/ace/