U148 Archive

Markdown archive served by Next.js

刀枪Blue

来源: BlogBus 原始链接: http://blogbus.com:80/blogbus/blog/diary.php?diaryid=20607 存档链接: https://web.archive.org/web/20050101130901id_/http://blogbus.com:80/blogbus/blog/diary.php?diaryid=20607 作者: zhouxiaohu

刀枪Blue 1001001 1001100 1010101 <<<乱想 | 首页 | 两个晚上>>> 2003-07-08 08:54 实时系统中的POSIX及Case Study Kevin M. Obenland Embedded Systems Programming 版权归原作者所有，zhouxiaohu翻译仅供参考 每个RTOS都有其专有API，不过其中一些也支持POSIX标准。本文考察POSIX中应用于实时系统的部分。 在今日的计算系统中，利用为业界接受的标准设计开放系统体系结构的软件正变得越来越重要。开发开放系统的需求被3个原因驱使着，第一，一个开发人员就能从头实现整个系统的日子已经一去不复返了。程序的规模正在不断变大，需要不断壮大的开发团队；第二，软件不再是孤立的，他们必须和数量极为庞大的商业软件共存；最后，软件应用程序的生命期通常都很长，增加新功能时需要进行各种修改和升级。 通过定义可以提高互用性和可移植性的标准软件接口，开放的软件体系结构适应了当今软件开发过程的挑战。公开发布的标准接口也减少了将来增加功能的花费。 当今的计算机系统中广泛使用了各种标准。各种新的标准也正在不断定义以满足软件技术不断变化的状态。一个标准不被实际使用就不会产生有效的作用，或者马上就会过时。要发挥有效的作用，标准必须基于公认的技术并且被工业界广为接收。 最初的Portable Operating System Interface for Computing Environment(POSIX)标准于1990年首次发布【1】。POSIX是基于UNIX的，后者在上世纪70年代已经成为一项被广为接受的技术。POSIX定义了应用与操作系统接口的标准方法。最初的POSIX标准定义了一些核心功能的接口，比如文件操作，进程管理，信号和设备。随后的POSIX发布还涵盖了实时扩展和多线程【1】。 在理想的世界里，由于前面提到的优越性，人们应该总是选择标准。不过在真实世界里，决定使用标准之前必须解决一系列问题。包括： 标准提供了我的应用需要的功能吗？ 标准的性能，或者标准的实现，是否适合我的应用？ 有这个标准的商业可用实现吗？ 本文将通过三个方面讨论POSIX在实时系统中的有用性：功能functionality，性能performance和可用性availability。由于实时系统通常对性能有严格的限制，重点将放在POSIX实现的性能上。 POSIX实时操作系统 POSIX标准家族包括30多个独立的标准，从基本的操作系统服务规范到测试操作系统对标准的符合程度的规范【2】。本文的重点是那些对实时嵌入式系统开发具有重要意义的标准。本节讨论实时系统并给出对相关POSIX标准的简要的review。 实时系统 实时系统的计算结果及时性是相当重要的【3】【4】。比如军用武器系统，工业控制系统和视频音频流。实时系统通常分为两类：硬实时和软实时。硬实时系统中deadline必须满足否则计算结果就是无效的。例如，在导弹跟踪系统中，如果导弹延迟了就可能错过目标。软实时系统的时间限制没有这么严格。如果没有满足deadline，计算结果可能仍然是有用的。音频流就是一个软实时系统的例子。如果一个数据包迟到或者丢失了，声音质量会降低，不过仍然是可以听见的。 为了保证实时系统的时间需求能够满足，下层计算系统的行为和时间特性必须是可预测的predictable【5】。系统时间性能称为可预测的的就是所有操作的时间必须有界。这意味着所有操作在最坏情况下的时间已知。不过有时，仅当其最坏情况时间和通常情况时间非常接近时系统才称为可预测的。 POSIX实时相关标准 在30多个POSIX标准中，表一列出的7个标准和实时嵌入式系统的开发非常相关。头3个标准1003.1a，1003.1b和1003.1c是被支持最广的。POSIX 1003.1a定义了基本操作系统功能的接口，它是在1990年1月被首个采纳的标准【6】。实时扩展定义在1003.1b，1003.1d，1003.1j和1003.21标准中【7】【8】【9】【10】。不过，最初的定义在1003.1b中的实时扩展是唯一被广泛实现的。进程中的多线程支持在单独的标准POSIX 1003.1c中提供。POSIX还在1003.1h标准中包括了高可用high availability支持【11】。 表一 POSIX标准 标准 名字 描述 1003.1a OS定义 基本OS接口；包括的支持有：单进程，多进程，作业控制，信号，用户组，文件系统，文件属性，文件设备管理，文件锁定，设备I/O，设备相关控制，系统数据库，管道，FIFO和C语言 1003.1b 实时扩展 实时系统需要的功能；包括的支持有：实时信号，优先级调度，定时器，异步I/O，优先级I/O，同步I/O，文件同步，映射文件，内存锁定，内存保护，消息传递，信号量 1003.1c 线程 支持单进程内多线程的功能：包括的支持有：线程控制，线程属性，优先级调度，互斥量，互斥量优先级继承，互斥量优先级天花板和条件变量 1003.1d 附加的实时扩展 附加的接口；包括的支持有：新的进程创建语义（spawn），sporadic server调度，进程和线程执行时间监视，I/O咨询信息，阻塞功能上的超时，设备控制和中断控制 1003.1j 高级实时扩展 更多的实时功能，包括：typed memory，nanosleep improvements，barrier同步，reader/writer locks，spin locks和persistent notification for message queues 1003.21 分布式实时 支持实时分布式通信的功能：包括的支持：缓冲管理，发送控制阻塞，异步和同步操作，边界阻塞，消息优先级，消息标签和实现协议 1003.2h 高可用 可靠性，可用性和适用性服务（SRASS）；包括的支持：记账，核心转储控制，关闭/重启和重配置 POSIX的商业支持有相当大的不同。由于POSIX 1003.1a是基于UNIX的，任何基于UNIX的操作系统会很自然的接近标准。要符合POSIX标准，操作系统和硬件平台必须使用一组测试通过认证【12】。目前，只有用于POSIX 1003.1a的测试集。由于POSIX被设计为一组可选的特性，操作系统提供商可以选择仅实现POSIX的一部分并且仍然是POSIX兼容的。兼容性只要求提供商说明POSIX的哪些特性实现了，哪些没有。这是混乱的一个根源，出于市场的原因，几乎所有的提供商都宣称他们是POSIX兼容的。 POSIX profiles 嵌入式系统通常有空间和资源限制，包含全部POSIX特性的操作系统可能并不适用。定义POSIX 1003.13 profile标准就是用来满足这种类型的系统的需要的【13】。POSIX 1003.13并没有包含任何新增加的特性，它将已存在的POSIX标准定义的功能分组为不同的功能单元。该profile基于操作系统是否支持多进程和文件系统。4个当前的profiles在表二中概述。 表二 POSIX 1003.13 profiles Profiles 进程数量 线程 文件系统 54 多个 Yes Yes 53 多个 Yes No 52 单个 Yes Yes 51 单个 Yes No POSIX实时扩展 POSIX 1003.1b以及1003.1d，1003.1j，定义了实时系统开发中有用的扩展。最初的实时扩展标准1003.1b中定义的功能已经被很多操作系统支持，后两个标准被支持的程度则没有这么广。出于这个原因，本文的重点在POSIX 1003.1b。POSIX 1003.1b中定义的特性的大概情况： 定时器timers：周期性timer，使用POSIX信号完成发送 优先级调度priority scheduling：固定优先级克可抢占调度，最少32个优先级 实时信号real-time signals：增加的具有多个优先级的信号 信号量semaphores：有名和内存计数信号量 内存队列memory queues：使用有名队列的消息传递 共享内存shared memory：多个进程共享的有名内存区域 内存锁定memory locking：防止物理内存页的虚拟内存交换 列表一是创建和使用POSIX timer的C代码。创建timer有两个步骤：指定timer到期时发送的信号，然后创建设置timer本身。例子中使用了最高优先级的实时信号SIGRTMIN来异步调用timer处理例程。必须指定timer的两个值：初始到期时间it_value和频率tv_sec。结构itimersepc允许纳秒级的时间规格，不过真正的精度和系统有关。POSIX调用clock_getres()可以用来确定真正的时间精度，通常是10ms或者1ms。 列表一 #include #include void timer_create(int num_secs, int num_nsecs) { struct sigaction sa; struct sigevent sig_spec; sigset_t allsigs; struct itimerspec tmr_setting; timer_t timer_h; /* setup signal to respond to timer / sigemptyset(&sa.sa_mask); sa.sa_flags = SA_SIGINFO; sa.sa_sigaction = timer_intr; if (sigaction(SIGRTMIN, &sa, NULL) < 0) perror(3sigaction2); sig_spec.sigev_notify = SIGEV_SIGNAL; sig_spec.sigev_signo = SIGRTMIN; / create timer, which uses the REALTIME clock / if (timer_create(CLOCK_REALTIME, &sig_spec, &timer_h) < 0) perror(3timer create2); / set the initial expiration and frequency of timer / tmr_setting.it_value.tv_sec = 1; tmr_setting.it_value.tv_nsec = 0; tmr_setting.it_interval.tv_sec = num_secs; tmr_setting.it_interval.tv_sec = num_nsecs; if ( timer_settime(timer_h, 0, &tmr_setting,NULL) < 0) perror(3settimer2); / wait for signals / sigemptyset(&allsigs); while (1) { sigsuspend(&allsigs); } } / routine that is called when timer expires */ void timer_intr(int sig, siginfo_t *extra, void cruft) { / perform periodic processing and then exit */ } POSIX 1003.1b提供了固定优先级可抢占调度的支持。要兼容POSIX，操作系统必须实现至少32个优先级。POSIX定义了3种调度策略操作同优先级的进程。SCHED_FIFO，按先进先出调度进程，进程运行直到完毕；SCHED_RR，调度器使用一个时间定额以循环方式调度进程；SCHED_OTHER，由实现确定调度策略。由于SCHED_OTHER与实现有关，所以在不同平台间没有可移植性，应该有限制的使用。 POSIX在多种机制中都使用有名对象，包括信号量，共享内存和消息队列。名字与文件系统名字类似，但是独立于后者。例如信号量，一个进程创建信号量，其他进程可以通过名字使用信号量。两个进程都可以进行释放sem_post和等待sem_wait操作。 POSIX线程 POSIX线程在一份独立的规范中实现，这意味着，它们的规范独立于其他实时特性【14】。所以，很多实时规范中的特性也记入了线程规范中。例如，优先级调度是在各线程基础上进行的，但是处理方式却类似于POSIX 1003.1b中的调度。线程的优先级和调度策略通常都是在创建时指定的。 POIX线程规范定义并且（或者）修改了POSIX的如下方面： 线程控制thread control：创建，删除和单独线程管理 优先级调度priority scheduling：POSIX实时调度扩展到包括对每个线程基础上的调度；调度的范围达到所有进程内的所有线程或者只在每个进程间 互斥量mutexes：用来保护代码的临界区；互斥量还包括防止优先级翻转的优先级继承和优先级天花板协议支持 条件变量condition variables：与互斥量联合使用，条件变量用于创建监管同步结构monitor synchronization structure 信号signals：能够向独立的线程发送信号 操作系统实现中POSIX的覆盖情况 表三展示了POSIX 1003.1a的兼容级别。LynxOS 3.1 release兼容所有三个标准。VxWorks只支持POSIX标准的一个子集，因为在v5.4及其以前的发布版本中，VxWorks基于单进程模型，没有包括任务内存保护。现在的发布版，VxWorks AE已经支持内存保护；不过，保护模式是用和传统POSIX进程模型不同的方法实现的。Linux提供了对基本POSIX API和线程的很好支持，不过丧失了诸如时钟和消息队列的特性。 表三 商业操作系统中的POSIX OS POSIX 1003.1a(Base POSIX) POSIX 1003.1b(Real-time extensions) POSIX 1003.1c(Threads) Solaris Full support Full support Full support LynxOS Conformant Full support 3.0.1基于草案，没有线程属性；3.1基于最终标准 VxWorks 部分支持；支持不需要进程模型的功能 部分支持；支持不需要进程模型的功能 通过第三方产品支持 IRIX Conformant Full support Full support Linux Full support 部分支持，不支持定时器和消息队列 Full support QNX Neutrino Full support 接近full support；不支持内存锁定 Full support 操作系统设计 操作系统的设计极大的影响着其作为实时系统使用的能力。这其中既包括操作系统内部设计也包括其提供给应用编程者的特性。本节的重点放在两个操作系统（Solaris和LynxOS）的设计和他们用于实时系统的适用性上。 实时操作系统需要的特性 实时系统通常由多个异步执行线索实现。这是由响应外部事件，控制异步设备的需求确定的。由于这种特征，RTOS必须支持多线程。并且，由于事件的重要性和发生频率是不同的，RTOS必须支持优先级概念以便时间关键任务不会因为非时间关键任务延迟。此外，任务间需要通信，因此，OS必须提供同步和通信功能。 RTOS还需要支持计时相关功能比如高精度定时器和时钟。定时器用于支持周期处理并可以用来侦测系统超时错误。时钟用来跟踪时间。通常的实时应用可能需要知道微妙或者毫秒粒度的时间。 考虑到性能的因素，操作系统必须是可预测的，并只增加最小的系统开销。正如先前讨论的，实时系统必须有确定的行为。这就意味着，所有操作的时间，包括操作系统功能，必须是确定的。为了达到确定，操作系统必须是可抢占的preemptable，即如果OS正在处理低优先级的任务的请求，它必须能够停下正在做的工作并转移注意力到更高优先级的任务。这样就防止了高优先级任务被操作系统永久延迟的情况。 Solaris Solaris是一个通用UNIX操作系统，运行于SPARC和Pentium系列CPU。Solaris拥有许多实时系统需要的特性【15】。这些特性有： 多线程的优先的内核 A multithreaded preemptable kernel 全局优先级模型global priority model：线程映射为轻量级进程，后者被分配优先级类priority classes，然后进行全局调度 可配置的时钟tick：时钟tick的频率可以改变，因此可以提高或降低调度器运行的频率 高精度的POSIX定时器：Solaris定义了一个附加的基于硬件能力POSIX定时器（CLOCK_HIGHRES），能够提供具有纳秒和毫秒精度的定时器。 优先级I/O流priority I/O streams POSIX实时API的附加支持：Solaris 8现在支持POSIX 1003.1b的所有内容 对称多处理支持：Solaris支持对用户透明的多处理。这就允许为实时处理保留处理器，增加了确定性。 Solaris线程实现 Solaris实现了用户级和内核级线程。用户级线程实现为一个用户应用级别的库，而内核级线程是内核看到的一个执行单元【16】。Solaris使用轻量级进程（LWP）机制在处理器上运行内核级线程。用户级线程到LWP的映射可以通过几种方法完成。如果多个用户级线程被映射到单个内核级线程，那么同一时间他们之中最多只能有一个是活动的。为了发挥多处理器的优势，用户级线程可以被一一映射到LWP。 图一演示了如何设置Solaris处理器以及处理器绑定可以用于指定专为实时任务服务的处理器【15】【17】。先使用psrset命令，创建单个或多个处理器的池。注意，除了一个处理器之外，其他都是符合条件可以包含在处理器集中的；为了处理集合之外的轻量级进程需要一个处理器。然后使用psradm命令，屏蔽处理器集合中的处理器上未绑定的中断。再使用psrset命令，在绑定的处理器集合中的处理器上运行实时进程。所有其他非实时进程和中断运行在实时处理器集合之外的处理器上。后面会提到，这种机制在实时处理及时性上有显著效果。 Solaris调度器 为了支持不同类型的调度策略，Solaris将每个轻量级进程运行于四个优先级类中的一个之中。这些类如表四所示【15】。中断服务例程不是正在调度的进程的一部分，把他们包括在表中是因为他们运行于比所有任务优先级都高的优先级上，因此可能影响普通的LWP处理。应用程序LWP运行于这三个类别中的一个：实时，系统或者分时。中断线程为不在中断服务程序中完成的中断处理而保留。 表四 Solaris优先级类 类 优先级范围 描述 ISRs N/A 异步中断服务例程，非调度的 中断线程 160-269 不在ISR中完成的中断处理；基于ISR的优先级调度 实时 100-259 时间关键任务；固定优先级可抢占调度 系统/内核 60－99 系统级函数 分时/交互 0－59 一般应用程序；OS可能动态调整优先级以达到公平 调度由两个过程组成：确定要运行哪个LWP，执行tick处理【18】。当调度器被调用时，就以最高全局优先级调度LWP。如果机器拥有多个CPU，调度器可以调度多个LWP。 调度的第二个方面是tick处理，后者在每个时钟tick发生时都执行。调度器必须扫描所有活动的LWP并且更新他们的状态。对分时线程，如果调度器发现一个线程分享CPU不够公平，可能增加该LWP的优先级。如果LWP拥有系统资源，Solaris也可能提升其优先级到系统级别。因为实时线程按照固定优先级调度策略运行，他们之上的tick处理极少。 LynxOS LynxOS是为实时嵌入式系统开发的UNIX类型的操作系统。Lynx内核是可抢占的preemptable，可重入的，最小footprint可达97KB【19】。 Lynx调度 LynxOS一种调度策略，256个优先级的固定优先级可抢占preemptive调度。时钟tick频率固定于100Hz，即限制定时器精度为10毫秒。调度器在异步事件发生和系统状态改变时被调用。 Lynx priority tracking。LynxOS使用称为priority tracking的机制操作不在ISR中完成的中断处理【20】。这和Solaris使用的中断线程类形成了对比。使用中断线程类的问题是，为低优先级任务进行的中断处理将运行于比高优先级任务的应用处理更高的优先级。这会造成优先级翻转。LynxOS解决该问题的办法是将中断处理的优先级联系到应用线程的优先级。256个任务优先级再分为512个优先级，应用线程使用256个偶数优先级而中断线程使用256个奇数优先级。如图二所示，中断线程运行于比他们对应的应用中断高half-step的优先级上。 中断线程作为设备的驱动程序的一部分为专门的设备编写，因此不和特定的应用线程相关。出于这个原因，LynxOS提供一种机制，设备驱动程序能够确定它正在为其运行的线程的优先级。用这个方法，中断线程可以调整其优先级到合适的级别。如果将来不同的应用线程需要相同的设备，中断线程可以改变其优先级。 测试操作系统的实时性能 这里使用的benchmarks分为两类：测量OS确定性的，测量某些特定的重要操作的延迟时间的。这些benchmarks提出的动机是前面讨论的实时性能需求。这些benchmarks测试核心操作系统能力，独立于任何真实的应用。同样，因为我们的兴趣在于确定最好的实时性能，所有实时线程都运行于最高实时优先级，benchmarks使用的虚拟内存锁定在物理内存中。表五概述了这里使用的6种benchmarks。 表五 实时benchmarks Benchmarks 描述 测试方面 参数 定时器抖动 创建一个周期线程，测量期望和实际到期时间之间的偏差 测量OS响应时间 定时器周期： （1，10，100ms） 响应 执行固定的处理负载，运行多次，测量执行时间 确定线程是否能够以确定的方式响应 处理类型：（添加，拷贝，whetstone） Bintime 调用tod时钟，测量两次调用的时间间隔 测量最大内核blocking时间 无 同步 测量线程到线程或者进程到进程同步的延迟时间 测量线程间和进程间上下文切换时间 信号量类型：（POSIX 有名/无名信号量，pthread互斥量，lynx信号量）；进程到进程或者线程到线程 消息传递 测量从线程到线程或者从进程到进程发送数据的延迟时间 测量进程间和线程间可能的数据吞吐量 数据buffer大小；进程到进程或者线程到线程 实时信号 测量两个进程间实时信号的延迟时间 测量POSIX实时信号的延迟时间 无 确定性benchmarks 表五中的前3个benchmarks（定时器抖动timer jitter，响应response和bintime）被设计用来测试操作系统确定性【21】。因为确定性意味着在所有环境下完成一个操作的时间都是确知的，我们通常只需要这些benchmarks的最坏情况时间。 定时器抖动测试的结构如图三所示。测试创建一个定时器，设置其在给定周期到期，然后确定真正到期时间。抖动定义为真正到期时间和期望到期时间之间的偏差。大多数现在的CPU都有一个stamp counter，在每个CPU周期更新。大多数操作系统中的POSIX函数clock_gettime使用这个stamp counter，可以给出高精度的tod时间。 第二个确定性benchmark（响应）测量10毫秒的固定操作的真正执行时间。计算一组每次单独执行的真正执行时间，确定应用响应时间是否是确定的。确定的操作由下面的三种不同操作中的一种的循环执行组成：添加（add），内存拷贝（copy）或者synthetic Whetstone benchmark（whet）【22】。 最后一个确定性benchmark（bintime）确定最大内核blocking时间。这个benchmark使用一个最高优先级实时线程，重复调用tod时钟，计算每次调用需要的时间。每次调用需要的时间包括：执行系统调用的时间，内核block的时间。由于执行系统调用的时间应该是常数，benchmark报告的最大时间和平均时间之间的偏差可以很好地指出内核中block耗费的最大时间。 延迟时间benchmarks 最后三个benchmarks测试操作系统的同步，消息传递和发送实时信号的能力。对一个实时系统来说，使同步和通信延迟时间达到最小是很重要的。所以操作的平均延迟时间应该短小从而使总的系统开销最小化。限定最大延迟时间和实现确定性都很重要。 图四列出了四个不同的同步测试。第一个测试中，一个单独的线程发送（signal S）然后等待（wait W）一个信号量。这个测试测量信号量系统调用的延迟时间。第二个测试使用信号量在两个线程之间发送。两个线程或者在单个进程中或者在两个不同进程中。系统开销在第一个测试中获得，第二个测试获得交替发送时间（roundtrip signaling time），从后者的一半时间中减去前者（系统调用开销）可以确定上下文切换时间。 最后一个测试评估操作系统处理优先级翻转的能力。这个测试使用信号量构建典型的优先级翻转情况（注：为清晰起见，图中没有画出信号量）。在一个低优先级的任务获得（A）资源而之后高优先级任务也会需要该资源的情况下，优先级翻转就会发生。高优先级任务阻塞等待在该资源上，如果一个独立的中优先级任务独占CPU的话，高优先级任务会被不确定地延迟。这是一种优先级翻转，因为现在中优先级任务比高优先级任务更优先的处理。解决该问题的典型方法是允许低优先级任务继承高优先级任务的优先级以便前者能够运行然后释放（R）资源。这个测试中，中优先级任务使用一个固定时长的循环操作。如果发生了优先级翻转，那么低优先级任务获得资源的时刻和高优先级任务获得资源的时刻之间的时间差至少是中优先级任务的固定时长操作的时间。如果OS同步机制防止了优先级翻转，上述时间差是极短可以忽略的。 消息传递benchmark使用POSIX消息队列在同一进程或者不同进程中的两个线程中测量延迟时间和数据传输吞吐量。最后一个benchmark测量POSIX实时信号延迟时间。 Benchmark结果 上节定义的benchmarks运行于两个不同的操作系统上：LynxOS 3.0.1和Solaris 8。表六列出了两个系统的细节。注意，两个平台的CPU是不同的。我们的benchmarks用来测量操作系统确定性，观察最坏情况时间，CPU的差别几乎对测试结果没有影响。不过，当比较平均时间的结果时应该考虑到CPU速度的差别。 表六 试验平台 平台 硬件 CPU（速度） 操作系统 CPU配置 Lynx Dell Pentium 2(266MHz) LynxOS 3.0.1 1 CPU Solaris(2 proc) Sun Ultra 60 SPARC(360MHz) Solaris 8 2 CPUs Solaris(1 proc) Sun Ultra 60 SPARC(360MHz) Solaris 8 1 CPU Solaris(1 rt) Sun Ultra 60 SPARC(360MHz) Solaris 8 2 CPUs, 1 CPU 保留用来运行RT benchmarks 表六区分了三种不同的Solaris配置。这些不同配置可以让我们研究使用多个CPU的影响。第一种配置按照Ultra 60现状使用两颗CPU。第二种配置中，其中一颗CPU被disable。最后一种配置，CPU中的一颗专门保留，实时benchmarks运行于其上。这种配置下，保留的CPU可以不受未绑定的中断干扰。 非实时的外部负载 Benchmarks是独立运行的，就是说，没有任何其他的用户进程在运行，从而不会引入非实时负载。通常实时系统会运行各种混合的应用，有些有实时要求有些没有。GUI就是非实时应用的例子。表七列出了用于产生非实时负载的处理的类型。负载包括CPU密集应用和使用中断I/O设备的应用，后者比如文件和网络子系统。 表七 非实时（重）负载 名字 描述 负载程度 CPU 处理Whetstone synthetic benchmark产生的负载 10ms every 100ms Disk 写文件操作 10ms every 100ms 中断 外部串口中断 1000 interrupts/sec 网络 TCP/IP socket transfers 4000 packets/sec 系统调用 Sequence of utility system calls 10ms every 100ms Memory Dynamic memory allocation 10ms every 100ms File search Search files in a directory and all sub-directories Continuous 定时器抖动 图五列出了所有平台的定时器抖动测试的结果。图五A，没有负载的情况下，所有平台的抖动时间都在可接收的200ms下。Solaris（1rt）的抖动最小。Lynx的抖动也很低。图五B，在重负载情况下，没有保留一个处理器的Solaris配置的抖动超过了限度。这些配置中，最坏情况的抖动达到了10秒之巨。 应用响应 表八列出了所有配置的最坏情况响应时间的结果。没有负载的情况下，所有配置的响应结果都非常接近基准值10毫秒。有负载情况下只有Lynx和Solaris（1 rt）配置接近10毫秒。标准Solaris平台（Solaris 2proc）的最坏情况结果比标准值差了3个数量级。 表八 最坏情况响应（毫秒） add copy Whet 配置 无负载 重负载 无负载 重负载 无负载 重负载 Lynx 9.9 9.9 10 10.1 10.1 10.2 Solaris(2 procs) 10.1 11236.5 10.7 12061.7 10.6 12162.8 Solaris(1 proc) 10.2 7310.7 10.2 4599.3 10.7 6328.2 Solaris(1 rt) 10 10 10 10 10.5 10.5 Bintime 图六显示所有配置的确定性bintime benchmark结果。无负载情况下，内核只有非常小的延迟。Solaris（1 rt）配置下，延迟小于10毫秒，其他配置下，延迟小于等于100毫秒。在重负载情况下，没有保留实时处理器的Solaris配置再次变得非常不确定。单颗CPU的Solaris配置的最大延迟接近1秒。 同步 本节提供前面描述的同步测试的结果。 测试1（单线程内 signaling） 图七演示了Lynx和Solaris（1 rt）配置的简单同步测试的结果。Lynx测试了四种不同类型的同步机制，Solaris测试了三种。如图七A所示，Solaris平台的最坏情况延迟时间比Lynx平台要好得多。两个平台上，增加负载对最坏情况时间几乎没有影响。 图七B显示了同样的同步机制的平均延迟时间。Lynx信号量有最大的延迟时间，很可能因为该信号量实现了优先级继承。Solaris的POSIX有名信号量延迟时间比其他机制的延迟时间都长得多，原因可能是信号量名字存放在文件系统中。 测试二（线程间signaling） 图八显示了Lynx和Solaris（1 rt）配置上的线程间signaling测试的结果。所有情况下平均和最坏情况交替时间Lynx都比Solaris好。更需要注意的是Solaris测试运行的处理器比Lynx测试运行的处理器还要快。图八也显示了所有类型的同步机制的延迟时间大致相同。 测试三（优先级翻转） 所有配置的优先级翻转测试结果在图九中显示。除了Lynx（lsem）案例的所有案例中，低优先级和高优先级任务共享一个用于保护资源的pthread互斥量。没有负载的情况下，第一个Lynx配置的延迟时间与中优先级任务的延迟时间10毫秒有对应关系。这说明了一个事实，LynxOS 3.0.1中，没有为pthread互斥量实现优先级继承。Lynx信号量没有这个问题。 Solaris中实现了优先级继承，没有负载情况下，所有Solaris配置的延迟时间都比较低。 高负载情况下，只有Lynx（lsem）和Solaris（1 rt）配置显示了可接收的延迟时间。Solaris 1rt和2 proc配置都受到了高负载的影响；因为缺乏优先级继承协议，Lynx配置仍然具有高延迟时间。 上下文切换时间。表九显示了所有平台的上下文切换时间，从头两个同步测试中的内存信号量结果计算而来。Lynx上下文切换时间比最好的Solaris配置下的时间的一半还少。同样，Lynx的进程到进程上下文切换时间只稍微比线程到线程切换时间长一点。 表九 上下文切换时间 无负载 重负载 线程 进程 线程 进程 配置 最大 平均 最大 平均 最大 平均 最大 平均 Lynx 42.2 20.1 47.2 24.2 40.5 20.1 53.2 24.0 Solaris(1 rt) 65.4 52.9 446.8 49.9 67.2 51.8 461.0 50.6 Solaris(1 proc) 198.9 53 459.1 50.3 160.8 53.2 23240 51.4 Solaris(2 proc) 247.5 48.1 119.6 41.4 7149.0 68.7 639191 82.2 Solaris线程上下文切换时间比进程切换时间确定得多。Solaris（1 rt）配置下，最大线程到线程切换时间接近平均值。然而，同样配置下，进程到进程切换时间比平均值差了一个数量级。另一个有趣的发现是，Solaris下进程间切换时间比线程间切换时间还稍微好一些。两种情况下，都存在LWP间的上下文切换，似乎说明了系统开销的bulk在调度器中。 通信 实时信号 图十显示了所有配置下的实时信号benchmark结果。Lynx配置比任何Solaris配置的信号延迟时间都小。并且，Solaris 1 proc和Solaris 2 proc配置都被增加的非实时负载严重影响。 消息队列 所有配置的POSIX消息队列延迟时间和吞吐量在表十中显示。Lynx平台的延迟时间比Solaris平台好，但是Solaris平台的吞吐量更好。后者更好的吞吐量可能是因为Solaris平台上更快的硬件造成的。 表十 POSIX消息队列（无负载） 延迟时间（usec） 吞度量（MB/sec） 线程 进程 线程 进程 配置 最坏 平均 最坏 平均 最坏 平均 最坏 平均 Lynx 50.1 30.5 57.7 35.9 46.2 51.6 45.9 50.0 Solaris(1 rt) 98.7 90.5 118.9 102.7 62.4 77.8 61.5 76.5 Solaris(1 proc) 152.8 89.6 159 102.4 77.7 77.3 72.9 76.3 Solaris(2 proc) 148.7 82.8 146.8 77.5 41.3 66.6 58.2 65.5 适用性 本文中我们已经评估过为实时嵌入式系统开发的软件中POSIX的使用情况。我们讨论了POSIX的特性以及这些特性在满足实时软件开发的需求方面做的如何。我们也实际评估了LynxOS 3.0.1 和Solaris 8这两个POSIX的实现的实时性能特性。 试验评估表明了LynxOS和Solaris可以适用于实时系统。LynxOS的所有操作的系统开销比较低，即使在高负载条件下也是确定的。 Solaris 8包含了很多对实时开发很重要的特性，包括高精度定时器，processor partitioning和SMP支持。后两个特性是Solaris用作实时操作系统的关键。标准Solaris配置的确定性和所有实时任务运行于专用处理器的配置的确定性之间的差别是相当明显的。标准配置是不适合于实时的，而第二个配置则非常确定。 尽管本次study没有进行Solaris和LynxOS的POSIX API之间详尽的比较，我们的结论是这两个POSIX的实现都have a good deal in common。最大的差别在时钟精度和实时优先级的数量上。如果需要比10毫秒更精细的时钟精度，可能会带来移植性问题。我们碰到的其他差别，比如LynxOS线程实现的差异，都已经在该操作系统的v 3.1版本中调整了。 参考

  1. IEEE/ANSI Std 1003.1: Information Technology- (POSIX)-Part 1: System Application: Program Interface (API) [C Language], includes (1003.1a, 1003.1b, and 1003.1c). 1996. Back
  2. IEEE Portable Applications. Available at http://standards.ieee.org/catalog/posix.html. Back
  3. Stankovic, J.A. Misconceptions About Real-time Computing. Los Alamitos, CA: IEEE Computer. October 1988. Back
  4. Jensen, E. Douglas. "Real-time for the Real World." Available at www.real-time.org/. Back
  5. Stankovic, J.A. and K. Ramamritham, "What is Predictability for Real-time Systems?" Journal of Real-time Systems, 1990. Back
  6. Lewine, D. POSIX Programmer's Guide. Sebastopol, CA: O'Reilly & Associates, 1991. Back
  7. 1003.1d Information Technology- (POSIX)-Part 1: System Application Program Interface (API)-Amendment x: Additional Real-time Extensions. 1999. Back
  8. 1003.1j-2000: Information Technology-(POSIX)-Advanced Real-time Extensions.Back
  9. 1003.21, LIS D3.0: Information Technology- (POSIX) RT Distributed Composite Insulators. 1999.Back
  10. Gallmeister, B.O. Programming for the Real World, POSIX.4. Sebastopol, CA: O'Reilly & Associates, 1995. Back
  11. 1003.1h D5, Draft POSIX Part 1: System API Extension-RASS. 1999. Back
  12. National Institute of Standards and Technology, PCTS: 151-2, POSIX Test Suite. Back
  13. 1003.13-1998 IEEE Standard for Information Technology-Standardized Application Environment Profile (AEP)-POSIX Real-time Application Support. 1998. Back
  14. Nichols, B., D. Buttlar, and J.P. Farrell. Pthreads Programming. Sebastopol, CA: O'Reilly & Associates, 1996.Back
  15. Scalable Real-time Computing in the Solaris Operating Environment. SUN White paper. Back
  16. Stallings, W. Operating Systems. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1998.Back
  17. Cockcroft, A. "Processor Partitioning." Performance Q&A. SunWorld. 1998. Back
  18. Mauro, J. and R. McDougall. Solaris Internals: Core Kernel Architecture, 1st edition. Prentice-Hall PTR/Sun Microsystems Press, 2000. Back
  19. The Lynx Real-time Operating System. Information available at www.lynuxworks.com/. Back
  20. William Weinberg. "Meeting Real-time Performance Goals with Kernel Threads." Available at http://www.lynux-works.com/ Back
  21. Obenland, K., T. Frazier, J.S. Kim, and J. Kowalik. "Comparing the Real-time Performance of Windows NT to an NT Real-time Extension." Proceedings RTAS. 1999. Back
  22. H.J. Curnow, B.A. Wichmann. "A Synthetic Benchmark," Computer Journal 19(1): 43-49. 1976. Back
  23. L. Monk, et al. "Real-time Communications Scheduling: Final Report." MITRE MTR 97B69. 1997. Back zhou @ 2003-07-08 08:54 返回页首 | 评论 | 引用(0) 评论 发表评论 最新文章 Qtopia PDA Edition Released Under GPL DoCoMo 投资 MontaVista ClusterKnoppix 集群 Tall Buildings Z4CK The Lord of The Ring: The Return of The ...? Generation Kill Kibertron Ultimate vehicle for DJs 过节 Links 弱水三千 阿巧 蜻蜓的世界 双子的空间 心的方向 carol 一头熊的碎碎念 小鸡芝芝 isaacmao TOPKU cnblog心得集 Gizmodo Weblogsinc Kuro5hin Engadget AlterSlash Vivisimo CleverCS DeskCity