英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
MiThOS - 一个实时微内核多线程操作系统
Frank Mueller Viresh Rustagi Theodore P. Baker
Humboldt-Universitat zu Berlin Microtec Research Inc. Florida State University
Institut fur Informatik 2350 Mission College Blvd. Department of Computer Science
Unter den Linden 6 Santa Clara, CA 95054 Tallahassee, Florida 32306-401910099 Berlin (Germany)
电话: ( 49) (30) 20181-276, : mueller@informatik.hu-berlin.
摘要
MiThOS(微内核多线程操作系统)是一个嵌入式系统的实验性操作系统。这个系统内核是POSIX“最小实时系统模型”的首次实践。它是基于P线程（POSIX线程）的库实现的先前工作。这个系统是前所未有的。它支持在具有共享内核和用户空间的单个进程环境中的多线程，实时任务映射到POSIX线程。它表现出显著的时间可预测性，旨在满足硬实时需求。这是通过精心设计的只有很少的设备驱动程序来实现的。该系统已在SPARC VME架构上实施和测试。该系统包括一种用于SPARC的快速上下文切换算法，它优于SunOS下的上下文切换，并与Solaris下的性能相匹配。它支持选择性启用和禁用可获取的硬件组件（MMU、缓存等）。此外，还提出了一种用于截止期调度的POSIX线程的实现扩展。总体而言，系统表现出比SunOS 4.x略快的性能，并且在其定时行为中更可预测。内核的应用范围从评估Ada95及其运行时系统中新语言特性的开销、验证裸机上的静态定时预测到提供操作符用于小型需要较高的定时可预测性的嵌入式系统。
1 介绍
最近，人们经常选择微核来设计实时操作系统[9，7，2]。然而，大多数系统实现了UNIX系统接口的一大部分。系统的额外功能往往会降低时间的可预测性并且导致更昂贵的内核调用。许多现代操作系统承认对更快、更简单的编程模型的需求。一个结果是一个进程中控制的单独线程的模型。这种模型的一个版本正在成为IEEE POSIX 1003.4a线程扩展标准，用于简化的Pthreads。草案6版本的Pthreads已经实现为SPARC体系结构的FSU Pthreads线程库[13]。据报道，该实现比基于内核的商业线程实现执行得更快。
本文描述了微核MiThOS。通过将FSU Pthreads线程库与SPARC体系结构的微内核集成，MiThOS实现了IEEE POSIX 1003.13草稿的“最小实时系统模型”的主要部分[10]。最小模型是用于“专用于无人控制一个或多个特殊I/O设备的嵌入式系统“，并且不支持内存管理。我们的系统正在逐步扩展，以最终支持整个模型。与较大的内核相比，系统的最小性使系统具有更好的性能和更好的定时可预测性。库实现和内核实现之间的性能评估可以在[4]中找到。这项工作表明，MiThOS的执行速度是UNIX之上的线程库的1到3倍，这取决于内核调用。测量还表明，MiThOS表现出重复程序执行时的非常可预测的定时行为。另一方面，在UNIX下，由于内核活动，时间可预测性有时会急剧下降。
实现MiThOS的动机之一是为GNAT（Gnu Ada9X翻译器）[17]提供一个嵌入式测试，并结合我们基于线程的GNARL（Gnu Ada9X RunTime 库）[8]。这样的测试环境提供了确定Ada95中机器开销与新语言功能的操作系统开销的手段。此外，它还允许我们研究如何通过实现特性来增强POSIX线程标准来更好的支持Ada95。另一个动机是为现代体系结构提供一个微内核，其源代码是公开的，可以修改或扩展。我们还使用微内核来验证裸机上最坏执行时间的静态预测[3]。
总之，本文描述了MiThOS在以下新问题上的设计和实施进展，这些新问题尚未得到报告：
- 有界中段（非周期服务器模型）
- 没有通用入口和出口代码的中断处理程序
- 普通优先例程
- 三级内存保护（用户，Pthreads内核，系统内核）
- 用户对低级硬件的控制（MMU，缓存等）
- 用户空间调用内核而不是陷阱
- 快速上下文切换
- 最后期限安排支持
2 MiThOS 微内核设计
在下面，描述了MiThOS底层微核的设计。高级内核功能的基本设计与FSUP线程库[13]的设计和实现是相同的。这种先前的的库的精心设计有意接近微核的高级设计。它包括一个用于内核操作的单片监视器，该监视器是通过简单地设置一个标志来输入的。如果执行调度操作，内核将通过调度器；否则，就是清除内核标识以离开内核。在[13]中可以找到对高级设计的更详细的描述，这里不再重复。
本节详细介绍了微内核的低级设计问题。它打破了传统内核设计的一些传统，以实现更好的性能和可预测性，并提供对硬件的全面控制。（例如MMU处理，缓存）
- 采用三级保护模式：首先，用户空间可以随时访问。其次，线程内核结构是在内核模式下访问的，通过单片监视器同步，但这些线程内核结构仍然可以在没有保护的情况下访问。因此，线程内核调用可以直接通过常规函数调用进行，而不需要陷阱的开销。第三，通过陷阱进入MiThOS内核模式，并允许访问较低级别的内核结构，如中断向量和设备地址。
- 内存保护仅限于代码的只读部分，MiThOS低级内核的可访问主管部分，以及线程堆栈底部用来检测堆栈堆栈溢出的不可访问内存。
- 可以控制缓存以选择性地启用和禁用指令和数据缓存，甚至只允许缓存某些内存页。
- 中断处理程序被限制为：定时器、串行I/O、以太网和VME内存。每个中断处理程序执行自己的处理程序，并可能抢占当前线程（见下文）。类似地处理同步事件（故障检测）以产生总线错误和分段冲突。
- 优先权是通过一个共同的例程来支持的。控件可以从任何中断处理程序传输到此代码。该设计集成了过程级信号的处理。
- 不支持虚拟内存管理。程序直接在物理内存中执行，以提供更好的可预测性。
在传统的内核设计中，大多数设备触发的中断共享一个通用的入口和出口代码来处理中断。入口和出口代码处理页面故障，解决体系结构特性，然后通过调用一个特定的设备驱动程序来解除不同的中断。因此，设备驱动程序可以主要用高级语言编写，而不是汇编。在MiThOS中，每个设备触发的中断都有一个单独的中断处理程序。基本的设备驱动程序功能（如时间保持或字符/块处理）在中断处理程序中执行。高级操作（如调度）是通过将控制从中断处理程序转移到公共抢占例程来执行的。设备驱动程序的这一较高级别部分是用C写的。同样，避免中断的解复用。设备驱动程序中最常执行的一小部分是在没有冗长的输入和退出代码开销的情况下执行的。请注意，这种方法有时被用于传统内核中某些经常执行的中断，例如定时器中断。
但在中断级别上，常见的抢占例程取代了传统UNIX实现的信号环境。抢占例程的意义取决于用户代码或内核代码是否被中断。
如果线程的用户代码被中断，并且中断处理程序确定需要执行调度操作，那么将控制转移到抢占例程。此例程进入内核（通过设置标识）并在中断处理程序的顶部创建一个新的堆栈框架。它会调用一个执行调度动作的例程，紧接着调用调度器。当前线程此时可能会丢失处理器占用。当线程重新控制处理器时，它将通过从中断处理程序返回来恢复其执行。
如果线程的内核代码被中断并且中断处理程序转移控制到优先例程，一个对应中断的进程级信号发出。中断的时间安排被推迟，即：抢占不会发生。然后，执行将通过从中断处理程序返回而恢复，但仍将在内核代码中。当内核离开时，将检查进程信号掩码，并在调度器尝试切换上下文之前处理挂起的信号。
3 SPARC的快速上下文切换
操作系统代码中经常执行的部分之一是上下文切换代码，特别是对于实时操作系统。在SPARC上的上下文切换期间，当前线程的所有寄存器窗口都被使用到线程的堆栈上，然后一个窗口将加载新线程的顶部框架。清空寄存器窗口需要访问特殊寄存器，这只是在主管模式下授予的。因此，SPARC上的操作系统使用专用的内核陷阱来执行此操作。
在SunOS4.x下实现上下文交换机只需将处理器的所有寄存器窗口连接起来。然而，线程不能在任何时候使用所有注册窗口。我们为SPARC设计并实现了一种只使用所使用的寄存器窗口的窗口刷新算法。实际算法在其他地方提出[12]。该算法对于加速SPARC上的上下文切换是必不可少的。我们评估了该算法的性能，并讨论了该算法在MiThOS下的时间可预测性，并将其与SUNOS 4.0.3e下的寄存器窗口进行了比较。在20MHz。我们还插值了这些结果，SPARC经典时钟在50MHz时SunOS 4.1.3和Solaris 2.3上的性能。得到的测量结果如图1所示。在SunOS 4.x下的寄存器窗口使用性能基本上是恒定的。这与所有寄存器窗口都被保存的观察是一致的，而不管实际使用情况如何。MiThOS实现显示了性能线性到调用深度的稳定增长。这是由于只有使用过的窗口有选择地使用，并可能导致1.1至2.3的加速系数（在20MHz的SPARC引擎1E上）。在Solaris 2.3下的性能也随调用深度线性增加（几乎）。在SunOS 4.1.3上，Solaris 2.3的加速系数为1.2至2.3（在50MHz的SPARC Classic上）。通过加速因子的插值表明，Solaris 2.3下使用的算法也只保存了当前使用的窗口。
快速上下文切换算法显示了可变的执行时间，这取决于保存的使用寄存器窗口的数量。因此，抢占的定时行为可能因寄存器的使用而不同。
人们可能会期望一个程序的最坏执行时间的可预测性会受到这种差异的不利影响。不过请注意，仅仅存在寄存器窗口就需要在定时模型中对这种特殊的“缓存”资源进行建模。即使在没有上下文转换的情况下，当程序帧的嵌套深度超过寄存器窗口的数目时，寄存器窗口被使用。假设一个跟踪嵌套深度的定时模型，在某一区间内，最坏的上下文切换开销是由该区间内所有可运行任务的最大可能嵌套深度给出的。与保存所有窗口的传统上下文交换机相比，这种估计限制了上下文交换机开销，并导致执行时间预测减少。
4 实时支持
POSIX线程标准指定了一个支持实时系统的通用接口。实现了严格的优先级调度和优先级调度。它支持常规互斥锁协议和可用于绑定优先级反转的优先级上限协议。实现的上限协议称为SRP（Stack Resource Proto col[5]），与传统的上限协议相比，可以减少上下文交换机的数量。
然而，POSIX线程标准没有为线程的最后期限调度指定任何接口。我们支持POSIX线程接口的实现扩展，该扩展与整个接口设计正交。扩展线程的调度属性以允许指定绝对开始时间，绝对期限和相对期限（见图2）。这些属性必须在用作线程创建的参数之前进行设置。当线程已经运行时，不能动态更改，但可以随时查询该值。
这些最后期限计划线程的语义如下：具有开始时间的线程开始执行的时间不早于其开始时间。一个有一个周期（和一个必需的开始时间）的线程在其先前的开始时间加上它的周期到达时被重新启动。如果线程未在其期间内完成其执行，在重新启动之前，将在其周期结束时调用用户定义的处理程序。对于具有截止日期（和所需开始时间）的线程，如果它尚未完成执行，则在到达截止日期时调用此用户处理程序。用户处理程序作为信号处理程序执行。它通常用于降低线程的优先级或通过调用pthread_exit()终止线程。
周期性线程是通过只创建一次线程和重复调用线程函数来实现的。这是在调用线程函数的包装器中完成的。包装器请求周期结束时线程指定的超时信号，并调用线程函数。如果执行在线程从线程函数返回的期间内完成，超时信号请求被取消，线程挂起直到周期到期。然后，重申这一进程。如果线程未在其周期内完成，用户处理程序是异步调用的。由于MiThOS系统调用是异步安全的，因此可以在此处理
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[254290]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
