基于服务体的操作系统体系结构.docx

基于服务体的操作系统体系结构
李宏基金项目: 本项目受到国家自然科学基金项目(60273042)和安徽省自然科学基金项目(03042203)支持
作者介绍: 李宏，男， 博士研究生，1975-，研究方向操作系统；吴明桥，男，博士研究生，1978-，研究方向操作系统；龚育昌，女，博士生导师，1945-，研究方向数据库，算法，操作系统，超媒体；赵振西，男，博士生导师，1937-，研究方向体系结构，超媒体，操作系统，开放性固件，低功耗。
，吴明桥，龚育昌, 赵振西
中国科学技术大学计算机科学技术系，合肥，230027
Email: hil@
摘要：在分析微内核模型特点的基础上，提出了基于服务体的操作系统体系结构，引入了执行流和服务体等新的系统抽象以及服务体间通信等相应机制。服务体模型具有微内核模型的优点，克服了其效率低下的不足，为融合单内核模型和微内核模型提供了一种途径。除了传统多地址空间操作系统外，服务体模型还可应用在单地址空间操作系统中。
关键词：微内核 服务体 执行流
中图分类法： TP316 文献标识码：A
Server-Block Based Operating System Architecture
Li Hong , Wu Ming-Qiao , Gong Yu-Chang，Zhao Zhen-Xi
(Department Of Computer Science And Technology Of USTC, He Fei , 230027)
Abstract: Server-Block based operating system architecture is presented on the base of analysis of the traditional microkernel,, introducing some new system abstraction and policy such as server-block, executive-stream and the communication between server-blocks. Server-Block model overcome the poor performance of microkernel and provide a unified approach to microkernel and macokernel。Beside the traditional multiply address operating system , the new model can also be used to implement the single address operating system.
Key words: microkernel server-block executive-stream
1研究背景
操作系统内核模型主要分为单内核和微内核两种，单内核模型效率高但结构性、可扩展性、可维护性均存在较大的不足；微内核模型目标是以统一的形式在一个系统内兼容多个不同操作系统，降低操作系统开发维护的开销。微内核模型以线程为系统基本抽象，以IPC为通讯手段，良好的体系结构使得该核模易于维护，易于分布式扩展并且可以模拟其他操作系统的语义。用户级进程/线程作为系统功能的提供者也给操作系统的调试带来莫大的方便，可以较为容易构建用户态操作系统的模拟调试环境。微内核的主要缺点是过大的运行开销，主要集中于过于频繁的上下文切换以及由于进程空间的隔离所带来的进程间通讯的开销[1]。直接使用微内核模型构造实际应用的操作系统是不现实的，使用内核级服务器代替用户级服务器作为一种改进的思路被提出并重新考虑微内核模型为系统的鲁棒性所带来的好处[2]。在这种思想的影响下微内核模型的典型代表Mach的商用版本实现中，文件、网络以及内存管理等关键代码重新被收到内核中运行在特权模式下。微内核的一种改进是使用“外核”（Exokernel）[3]思想将内核服务进一步简化，对外只提供”虚拟机”抽象。文件、网络、缓存等机制由用户库完成，减少了上下文切换和信息交换的开销具有很高的效率。MIT开发的Aegis就是在这种思想指导下设计实现的操作系统。单地址空间操作系统模型[4][8]则从另一个角度避免上下文切换以及信息共享所带来的开销。单地址空间模型具有良好的运行效率，易于实现单层次以及持久存储系统。单地址空间操作系统面临的主要困难是要求运行平台提供大的虚拟寻址空间，同时难以完全兼容UNIX语义。
本文介绍一种新的操作系统内核模型—服务体模型。在服务体模型中消息传递仍然是通讯的基本方式，这是实现系统灵活性、开放性以及可扩展性的基础。服务体模型中消息的处理模式只支持同步方式，操作系统的异步功能由相应的服务体实现而不像微内核模型那样作为一种通讯机制提供给上层使用。这种消息处理模式的设计是基于以下理由的：（1）在微内核模型中绝大部分服务都是同步的，也就是Client要等待Server完成请求处理。（2）跨越服务器边界的通讯切换必然伴随着内存上下文的切换和线程调度。(3) 操作系统的异步服务没有必要以一种基础通讯协议的形式提供，异步处理完全可以在同步通讯协议的基础上加以实现，就如同传统的UNIX所实现的异步系统服务一样。
同步消息处理模式使我们可以采用一种新的系统抽象：执行流。执行流是比线程更基本的概念，执行流是CPU对指令的执行的抽象，是一种动态的概念。与线程不同执行流不拥有地址空间、栈等资源。因此执行流可以跨越操作系统功能组件的边界而且使得地址空间的管理更加具有灵活性。服务体是系统的基本组成单位，是一种静态的概念。服务体拥有地址空间、运行栈以及安全描述符、数据、代码等资源，依靠执行流完成服务，在这里执行流体现的是一种“推动力”的作用。通过使用执行流，服务体模型有效的减低了运行开销同时保持了和微内核模型相当的灵活性和可扩展性。服务体模型的一个有趣的特性是它能够匀滑的在单内核模型和微内核模型之间进行转变，从而将两种完全对立的模型统一起来。
本文首先详细描述了服务体模型的基本要素和工作原理，然后介绍了一个基于服务体模型的一个实例MiniCoreV3，并对其性能进行了分析。
2．服务体模型的基本结构
服务体模型的基本结构包括执行流、服务体，服务体空间、服务体管理器，核心内核等要素，各部分的关系如图一所示。服务体是操作系统的基本组成单位，服务体管理器提供服务体间通讯、服务体异常处理以及消息广播等机制；核心内核是一个特殊的服务体，负责提供如执行流、系统异常、陷入、时钟服务、系统同步等功能。

③

执行流

①
②

执行流

通讯控制块
通讯控制块
④
通讯控制块
⑤
服务体
服务体
核心内核
服务体管理器
①原始执行流 ②虚拟执行流 ③服务体注册的小端口列表 ④订阅消息
⑤服务体间通过消息进行通讯
图一 服务体模型结构

2.1执行流
在服务体模型中我们以执行流作为系统基本抽象。执行流与线程有类似之处，如具有优先级、是调度的基本单位、拥有保存CPU硬件上下文的数据结构等，二者的区别是执行流不与固定的地址空间绑定，或者说执行流不拥有地址空间。进而言之，我们通过将系统拆分成服务体（静态部分）和执行流（动态部分）两个概念以强调CPU运行力的抽象，执行流所代表的就是CPU对机器码执行的抽象。从推动服务体意义上来说各个执行流是等价的，一个任务由哪个执行流完成是无区别的，这就使得执行流能够直接跨越系统组件边界（往往也是地址空间边界）完成服务而不必像微内核模型那样必须使用不同的线程。这种抽象方式的另一个优点是在内存空间的使用可以更灵活以减少不必要的运行开销。应该说执行流是比线程更加基本的概念。
执行流根据用途分为普通执行流和工作者执行流两类。普通执行流用来推动用户程序，当用户发出请求时该执行流推动相关服务体完成请求处理，当消息的处理需要在单独的执行流中完成的时候，服务体则为它的某个小端口申请工作者执行流并使用该执行流完成消息的处理。对于频繁经常使用工作者执行流的服务体通过将工作者执行流和小端口绑定以提高效率，绑定方式分为两种：固定式和周期式。服务体使用周期性的工作者执行流完成一些周期性的任务，如协议栈状态维护、缓冲区的刷新等。一个小端口可以同时申请多个工作者执行流以加速处理。
系统中每个CPU提供一个原始执行流，如果采用超线程技术（Hyper-Thread）则每个CPU可以提供超过一个的原始执行流。核心内核中的执行流管理器将原始执行流变换成若干个并发的虚拟执行流，核心内核可以说是整个系统的动力之源。
2.2服务体
概括的说，服物体是具有通讯功能，拥有地址空间、安全控制等资源和属性的能够完成某一功能的代码和数据集合，可以看作是进程和模块这两种分属微内核和单内核两种不同内核模型的概念的一个综合体。服务体是系统的基本组成单位，用户程序包括驱动程序在内的各种功能组件都以服务体的形式存在，传统的用户程序模型(进程/线程）通过运行环境服务体实现兼容。服务体本是一种静态的概念，他的生命周期并不依赖执行流，具有持久性。服务体间基于消息进行通讯，在执行流的推动下进行消息处理。服务体模型中通讯的主体是服务体而不是进程或线程。通信使用的是服务体管理器所提供的服务体通讯机制而不是进程间通讯机制，这一点上与微内核模型有很大的区别。
服务体
其他服务体注册的小端口
异常插口
广播插端口
命令插口
本服务体小端口列表
服务体控 制块
图二 服务体管理数据结构

每个服务体可以视情况具有若干个小端口，所谓小端口指的是一个消息处理例程入口以及相应的属性，包括优先级、使用的地址空间、运行栈以及存取权限等信息，执行流只能从小端口进入一个服务体的内部，并根据记录的信息进行资源和状态的切换。由于每个小端口具有不同的控制信息，因此对从不同的小端口进入的执行流服务体也会呈现出不同的视图。一个服务体的所有的小端口都注册在一张表中，该表由服务体管理器负责管理。服务体管理器为每个服务体准备了三个标准的插口：命令插口、异常插口、广播插口。按照执行流流动的方向来分类，命令插口是输入端口，其他为输出端口，是消息的发布点。错误插口、广播插口是两个小端口链表，通过服务体管理器提供的注册机制，一个服务体可以将自己的小端口注册在其他服务体的错误插口或者广播插口上来订阅该服务体所发出的异常或广播消息，其结构如图二所示。当在这两个端口抛出消息时，服务体管理器将依次是用所注册的小端口来处理这些消息。如果没有指明，其他服务体发来的请求消息均使用命令端口进行处理。
微内核模型在处理消息时线程是不能跨越进程边界去完成服务的，因此引起了过多的上下文切换开销。开销包括：1. 选择合适的线程；2. 上下文切换；3. 地址空间的切换以及由此而带来的数据交换的开销。服务体是在执行流的驱动下运行，因为执行流是等价的，使用哪个执行流并没有区别，所以处理请求时执行流可以跨越多个服务体边界。这样就减少1、2 两项的开销。服务体也可以根据需要拥有自己的执行流。一个有趣的结论是在极端情况下如果每个服务体都拥有独立的执行流，服务体模型最终也就退化成微内核模型。我们把该问题放到2.5节中去讨论，有关地址空间的讨论则在2.3节中。
2.3 地址空间和运行栈
服务体的逻辑空间分为基本空间和扩展空间两部分。所有服务体的共享同一个基本空间，根据需要服务体还可以拥有属于本服务体一个或多个扩展空间。
扩展空间

基本空间
①
②

图三 服务体空间
②

②

服务体A
服务体B
①运行库 ②数据

基本空间为不同的服务体共享，从而有利于服务体间高效的信息传递,尤其是对经常处理大数据的服务体如文件、网络等。基本空间位于系统地址的高端，且是不可换出的以提高系统的运行效率。服务体对基本空间的访问控制基于capability机制[4][6]，只能访问所授权的地址段从而实现系统的健壮性和安全性。
扩展空间是服务体所私有的，私有空间是分页管理的，可以根据需要交换到后备存储器中以优化系统内存的使用。服务体可以将大的私有数据和运行的时候所需要的动态运行库加载到其私有空间中而经常使用的部分被加载到基本空间中以提高效率。由于扩展空间的内容私有于服务体，所以当使用扩展空间的数据作为参数传递给其他服务体的时候，应首先映射到基本空间内。地址的映射由内存管理服务体完成，通过使用Copy-On-Write的机制实现服务体扩展空间内的数据共享。一个服务体可以根据需要可以拥有多个私有空间，从而使所管理数据的容量超过硬件所带来的虚存空间限制。在MiniCoreV3中，Cache服务体利用了多个扩展空间从而为每个打开文件分配了更大缓冲窗口，提高了Cache性能。
服务体的地址空间信息记录在小端口中，同一服务体的不同小端口可以具有不同的地址空间信息，执行流通过小端口进入服务体时加载该小端口中记录的地址空间信息，如果服务体只使用基本空间则仅加载存取内存控制信息。系统中的全部执行流由核心内核产生，并默认的绑定核心内核的基本空间。
服务体提供执行流运行所需要的栈，当执行流进入通过小端口进入服务体时要进行堆栈切换。初始的时候执行流的产生者--核心内核为每个新创建的执行流提供一个位于基本空间的堆栈，出于安全或空间的考虑每个服务体也可以为自己的小端口配备一个或多个分离的堆栈空间。栈一般位于基本空间内，也可以位于扩展空间以满足对堆栈大小有特殊要求的情况。一个小端口堆栈的数量决定了能够同时进入该小端口的执行流的数量，从这个意义上讲每为小端口配备一个堆栈，相当于在微内核模型中为服务进程中增加了一个服务线程。
2.4 核心内核
核心内核是一个特殊的服务体，它屏蔽了大多数的处理器具体细节，为其他服务体提供包括执行流管理，中断管理、异常管理，时钟服务，工作者执行流管理以及内核同步等多种基础机制。核心内核同其他服务体一样，使服务体通讯机制同其他服务体通讯。
中断、异常由核心内核捕获并以错误（对异常事件）或者广播（对于中断）的形式向外发布。消息中包含了异常/中断编号，以及描述该错误的参数如发生错误的指令地址等。需要相关异常、中断消息的服务体可以通过订阅核心内核的相关消息来捕获相应的消息。在MiniCoreV3中，Linux运行环境正是通过订阅核心内核的异常消息捕获系统服务请求的，并将用户请求转发到对应服务体。设备的中断服务例程并不在中断消息中完成，核心内核实现了一个功能更加完善的实时中断处理机制用以处理设备中断。
核心内核负责将系统中的原始执行流变换成若干虚拟执行流，系统中所有的执行流均由核心内核产生。需要执行流的服务体向核心内核提出申请并注册一个小端口，注册的小端口中有服务体的地址空间、栈以及消息处理函数地址等信息。发生执行流切换的时候当前指令寄存器作为新的消息处理函数被写回到该小端口中，在调度的时候原始执行流通过向所注册的小端口写入一条空消息来恢复该虚拟执行流的运行。
3 服务体模型的工作过程
3.1 建立服务体连接
使用一个服务体所提供的服务前，首先应该与该服务体建立连接。服务体管理器提供Connect命令来完成此功能。目标服务体的每个连接都使得该服务体的引用数增加一，释放时引用数减一。服务体的引用数为0时意味着可以从内存撤出。Connect根据所提供的服务体的名字和小端口号给目标服务体发送连接请求消息，由该服务体并对各项安全指标进行认证，如果通过认证则返回代表连接的描述符。如果目标服务体不存在服务体管理器则会抛出一个错误，动态加载服务器通过订阅该错误实现服务体的按需加载。
3.2 消息的发送和回复
服务体管理器提供了基于消息的通讯机制，减在消息的处理上利用执行流的等价性，通过复用执行流避免了不必要的上下文切换开销。在此需要介绍两个具有代表性的核心元语：PokeMessage、ReplyMessage。服务体模型使用PokeMessage将消息写入一个服务体的小端口，ReplyMessage用来回复消息表明该消息处理完毕。
PokeMessage的算法：
输入 消息、目标服务体的小端口
（1） 对指定小端口进行消息重定向处理，见2.3.3节。
（2） 根据小端口的属性切换资源和运行状态包括地址空间、堆栈、调度优先级、存取控制信息以及运行特权级等，必要时阻塞当前执行流以等待空闲的堆栈资源。
（3） 使用小端口处理该消息。
（4） 检查消息中的Complete位是否为”完成”(该位由回复元语设置)，否则当前执行流睡眠在该消息上等待该位变为”完成”。
（5） 恢复执行流所绑定的资源。
ReplyMessage的算法:
输入 消息
（1） 设置所回复消息体的Errcode位和Complete位。
（2） 如果有执行流睡眠在消息的等待队列上，则唤醒这个执行流。
根据服务体对消息回复的时机可以将消息处理分为立即型和延迟型两类，如图四所示。立即型指的是小端口中的消息处理例程直接完成了消息的处理并在返回前使用ReplyMessage对消息进行回复；延迟型消息处理只是将消息暂时挂在消息队列上并不处理，执行流被阻塞在该消息上一直到该消息被处理完毕并回复为止。挂在队列上的消息由其他执行流负责处理和回复。绝大多数的请求都是立即型的，只有为了优化合并相应的请求或者使用工作者执行流处理相应的消息等个别情况下才使用延迟型的处理方式。
消息处理对提出请求的服务体来说是总是同步的，服务体模型不支持异步通讯方式。这不影响操作系统实现异步的操作，异步功能可以通过服务体间更高层的约定协议来实现。

唤醒操作
服务体
②
消息队列
服务体
等待队列
请求执行流
服务体
【立即型】
消息队列
请求执行流
回复消息
①
【延迟型】
其它执行流
图四 消息回复机制
3.3服务体重定向
消息的重定向可以实现层次化的消息处理。消息重定向系指的是将本来发送到服务体A的消息都转发到服务体B。消息的发送算法需要对消息的重定向进行处理，算法如下：
ReplyMessage的算法：
输入 小端口
1. 根据目标服务体的控制块，得到重定向服务体的控制块。
2. 检查重定向服务体控制块与目标服务体控制块是否相同，如果一致则算法停 止，消息被写入目标服务体的相同名字的端口中。否则将重定向服务体控制块作为目标服务体句柄并重复步骤（1）。
使用多个服务体层次会提供很多好处，尤其是对于设备驱动服务体。例如，它允许把高层协议问题与特定的基础硬件的管理分开，从而有可能支持多种硬件而不必重写许多代码，并可通过对同一协议设备服务体在运行时插入不同的硬件驱动程序来提高灵活性，还可把硬件限制对设备的用户隐藏起来，或者增加硬件自身不支持的功能。层次化插入服务体实现了对系统增加或删除功能的透明的支持，不必对同一个产品维护多个代码，并为动态的修正系统错误提供了一种方法。
3.4错误和广播
服务体模型提供统一的错误以及广播消息处理制，一方面服务体可以从错误端口或广播端口发布错误或者是广播消息客户，另一方面服务体可以使用自己的小端口来订阅其他服务体的错误消息或者是广播消息。消息的广播主要用于若干个模块的协调，如通过订阅内存管理服务体所广播的内存紧缩消息，服务体能够在合适的时候缩减各自的缓冲内存；错误的发布机制则将错误的处理与错误的抛出分离开来从而实现错误处理的结构化。
处理一个服务体所发布的错误或是广播的算法基本是相同的，都是依次咨询相应端口上所注册的小端口。对错误处理而言如果没有任何小端口能够处理所发布的错误消息，则该错误被转发到服务体管理器的出错端口上，在那里将有默认的动作来处理这些错误。其他服务体也可以通过向服务体管理器订阅这些错误来改变这些默认的动作。
四．基于服务体模型的实现---MiniCore V3
MiniCore V3[7] 是使用服务体模型设计实现的操作系统的原型系统，目的是对服务体模型进行研究。MiniCore V3使用运行环境服务体来实现现有多地址空间操作系统（如UNIX）如进程控制、调度机制以及用户API在内的基本特征从而兼容不同的操作系统。运行环境通过订阅核心内核的广播消息即捕捉到系统异常以及用户服务请求（Linux运行环境订阅了0x80号陷入异常）并转换为对不同服务体的请求消息。这种将异常组织成消息并通过订阅/广播机制在不同的服务体中传递的机制，使得很多利用异常加速处理的算法，如Cache管理、内存有效性检查等以更加清晰的方式组织起来。在MiniCore中我们已经实现了嵌入式实时运行环境RT-1和Linux的运行环境，其中Linux运行环境目前已经实现60个核心系统调用，包括文件、内存管理、进程调度、信号处理、网络等部分，支持Gcc,As,Vi，Telnet等部分Linux应用程序。
我们对MiniCoreV3性能进行了测试，方法是挑选Linux运行环境中有代表性系统服务，统计系统服务总的运行时间和由于服务体模型引入的包括包括通讯和上下文切换在内的运行开销，通过观察二者的比例来了解服务体模型的运行开销，表1是测试结果。这种测试方法避免了将运行结果直接与Linux相比较而带来的不公平：（1）Linux运行环境是重新编写的，数据结构、算法、程序编制技巧都与Linux内核不同，这些因素能够极大的影响运行时间开销。（2）由于所实现的Linux运行环境是一个功能子集，由于少了很多功能限制，这一点也会引起运行时间的不同。以上因素都导致将数据直接对比并不能反映服务体模型的运行开销情况 。
在表1中A是得到进程号（GetPid）；B是创建新的进程（Fork）；C是内存的匿名映射（Mmap），映射的内存大小为1M； D是父进程向子进程发送信号（Kill）；E是加载ELF格式可执行映像（Execve）。
表一 Linux运行环境部分服务测试结果 （us）
编号 测试服务 总运行时间 服务体机制所耗时间 比例(百分比)
A GetPid 0.7 0.087 12
B Fork 450.3 26.6 5.90
C Mmap 95 1.68 1.75
D Kill 16.7 0.13 0.78
E Execve 174352.3 702.2 0.40
从上表可以看出在服务体模型所引入的开销是很小的。为进一步测量消息机制的运行开销，我们在MiniCoreV3的Linux运行环境中长时间运行各种程序，然后收集在运行期间消息机制所占用的时间开销。经过长期运行，采集的数据表明服务体模型各种机制所引起的平均开销小于百分之2，微内核模型系统开销则要高于百分之20甚至更高[6]。
表二 路由性能测试结果
CPU
8MHz的嵌入式i386
300MHz 赛扬处理器
RAM
2M
64M
Flash
2M
无
网络控制芯片
8390
8390
操作系统
MiniCore V3
Win98
路由软件
MiniCore内置
WinGate
转发速度
300K/S
350K/S
为对服务体间通讯开销、中断处理以及设备管理、设备驱动程序通讯等综合性能进行评价，我们研制了一个路由器硬件试验平台，该平台以MiniCoreV3作为操作系统，并在该操作系统上运行了一个网络地址转换程序事先多台计算机共享一个Internet连接。该程序的运行运行数据与Win98、300MHz微机的同样数据的测试对比如表二。实验数据表明二者之间的速度非常相近，考虑到平台间的性能差别，这些数据可以直观的表明服务体模型在服务体通讯、中断的处理、驱动程序的组织等方面具有很好的运行效率。
五 结论
本文介绍了一种新的操作系统模型，提出了执行流、服务体等系统抽象，将单内核模型特征融合到微内核模型之中因此具有根大的灵活性和高效性，其特点如下：
（1） 保留了微内核良好的结构性和可扩展性。服务体之间通过消息进行信息交换，不必关心服务体的具体位置使得服务体模型很容易应用在分布式系统当中，另一方面用户可以根据需要选择满足需要的服务体方便的实现系统功能的剪裁。
（2）良好的运行效率。在服务体模型中使用了执行流的抽象，由于执行流的等价性因此可以跨越服务体边界完成用户服务，减少了上下文切换的次数。由于将地址空间与执行流相分离，地址空间的切换被延迟到必须发生的时刻，并通过共享的基本空间降低了服务体间信息交换开销。
(3) 提供了统一了单内核模型和微内核模型的一种途径。如果每个服务体只具有基本空间、不使用分离的栈且消息处理方式都是立即型的，服务体模型就相当于单内核（由于基于消息的通讯方式，扩展性、错误处理以及对分布式的支持仍然优于单内核模型）；如果每个服务体都具有扩展空间且所有代码、数据均在扩展空间里，使用分离的栈且所有的消息处理均为延迟型的，服务体模型就成为于微内核。服务体模型的这种特性为操作系统的设计者在效率、安全性等方面的权衡带来很大的灵活性。
(4) 既可以实现单地址操作系统[5]也可以实现多地址空间操作系统。当所有服务体都是用基本空间且应用程序也组织为服务体，即可实现单地址操作系统，小端口中的地址控制信息实现内存保护。多地址空间操作系统可以由运行环境服务体使用多个私有空间来实现。服务体模型同样可以在这两种模型间平滑过渡。
服务体模型尤其适合嵌入式系统这种对系统结构性和运行效率都有较高要求的场合以替代微内核模型。通过构造MiniCoreV3进一步证明了这种模型的可行性。

Reference
(1) Hohmuth, Jochen Liedtke.The Performance of u-Kernel-Based Systems.in Proceedings of the16th Symposium on Operating Systems Principles , 1997.
(2) Jay Lepreau, Mike Hibler . In-Kernel Servers on Mach 3.0: Implementation and Performance. Appearedin Proc. of the Third Usenix Mach Symposium, Santa Fe, NM, April 1993
(3) D.Engler. The Exokernel operating system architecture. PhD thesis, Massachusetts Institute of Technology,1999
(4) Gernot Heiser, Implementation and Performance of the Mungi Single-Address-Space Operating SystemSoftware: Practice & Experience, 28(9), 901--928 ,July 1998
(5) Bryan Ford, Jay Lepreau. Evolving Mach 3.0 to a Migrating Thread Model. In Proc. of the Winter Usenix Conference, January 1995
(6) S. Shapiro, EROS: a fast capability system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles, pages 170--185, 1999.
(7) 李宏，吴明桥，MiniCore体系结构设计，中国科大信息处理实验室技术报告，2002
(8) 刘福岩,尤晋元，从多地址空间到单地址空间再到无地址空间，软件学报，2001.3