CN1667573A - 基于服务体/执行流模型的操作系统 - Google Patents

Abstract

本发明涉及一种基于服务体/执行流模型的操作系统，该模型由服务体和执行流两类机制构成；每个服务体均具有自己的服务体地址空间，服务体之间采用消息推动通信；所述执行流是物理CPU沿着指令计数器指示的指令执行顺序执行指令而形成的一条轨迹，该执行流是连续的；所述服务体用于实现操作系统中所有功能组件的功能，执行流只有通过小端口才能进入服务体；系统中其他系统软件和用户程序也以服务体形式加载到操作系统上；所述若干服务体中设置一个核心服务体，用于引导执行流通过服务体的小端口进入服务体并提供基础服务。该模型在实时性、多处理机支持、可扩展性与可维护性以及对分布式处理和对主动网络支持上具有明显优势。

Description

基于服务体/执行流模型的操作系统

技术领域

本发明涉及用于计算机系统中的基础软件，特别涉及一种基于服务体/执行流模型的操作系统。

背景技术

目前操作系统均采用进程/线程模型，如图1所示，其一个线程对应一个虚拟CPU，从而对用户隐藏了物理CPU的相关信息，提供了一个清晰的编程模型，当系统增加物理CPU的个数时可以得到较好的加速比。但是，由于进程/线程模型将数据的存储和对数据的计算紧密耦合在一起，而且采用了虚拟CPU的概念，从而导致了如下主要的缺点：

(1)线程之间的通讯是异步的，不可避免的会带来信息处理的延时或丢失，延时的不确定性又限制了系统的实时性。当发生事件的重入时，由于通讯是异步的，线程无法感知该事件被再次激活，从而会造成事件的丢失或延迟。在现有操作系统的进程/线程模型下很难有效的解决这个问题。

(2)线程/进程抽象忽略了线程之间大量的同步关系，一律采用异步方式，通过共享内存的方法来运行逻辑上的同步，其结果是给系统造成大量不必要的睡眠、唤醒以及调度等复杂的操作，增加了运行开销，降低了系统的效率，还使得分布式系统中的进程的迁移成为难以解决的问题。

(3)进程/线程模型屏蔽了物理CPU的相关信息，不利于编写高效的程序，特别是对于多处理器系统，用户编程时不知道系统中真实处理器的数量，从而丧失了对线程调度的参与机会，线程调度只能靠调度器采用预测方法决定，而预测方法使系统更复杂而很难得到预期的效率。

基于进程/线程模型构造操作系统的具体方法可分为单一大内核和微内核两种构造方法。

如图2所示，单一大内核结构的操作系统在内核部分通过函数调用表达执行流，而在内核之外用户程序使用的则仍是进程/线程模型，单内核强调的是引导物理CPU执行内核代码，并通过简单的函数调用而不是通过进程/线程间通讯使执行流在模块间流动。

单一大内核操作系统的显著优点是高效率，因此被广泛使用，但其缺点也日益显露出来，主要表现在：

(1)由于系统模块间高度耦合，而且进程间缺乏有效的交互手段，所以功能的扩充只能通过在内核中增加相应的模块实现，这就要求系统开发人员深入掌握内核的数据结构和算法，而这是普通用户很难做到的，因此这种操作系统的可扩展性很差。

(2)所有内核模块都运行在核心态，都处于同一个内核空间，各部分缺乏保护，因此，内核模块中的错误可以导致整个系统崩溃，难以保证系统的高可靠性，而且，难以实现内核的升级。

(3)由于内核模块之间不具备隔离性，因此一个模块所造成的错误很有可能以一种不易察觉的方式传播给其他模块，这种错误可能在发生后经过相当长的时间以多种形式反映出来，错误的排查、定位十分困难，因此，系统的健壮性较差。

(4)由于所有的模块通过连接器相互连接，所以当一方的参数、语义发生变化时往往要影响系统的很多部分都要进行相应的改变，否则就容易造成难以排查的错误，构造一个系统只有约定了版本号的组件才可能一起正常的协作，这给内核组件的归档、维护、发布、移植等都带来很大的困难，因此，系统的可维护性较差。

(5)由于内核各部分的通讯是基于函数调用的方式，在实现分布式处理上难以将一个模块提供的服务透明的传播给其他的处理机，因此，系统难以有效的支持分布式服务。

如图3所示，微内核模型是卡耐基梅隆大学针对单内核结构的上述缺点，尤其是在支持分布式计算等方面遇到的困难提出的，与单内核模型相比，微内核模型在结构上也有一个为系统内所有进程所共享的内核，所不同的是几乎所有的系统服务都从内核中移出，由内核外的用户级进程实现。

微内核结构在可扩展性、可维护性等方面具有明显的优越性，并可通过位置无关的进程间通讯机制将服务透明扩展到分布环境中。其缺点是，由于引发了频繁的进程间通讯导致了运行的低效率，尽管采用诸如Hand-off调度、高速IPC、调用门等技术可以在一定程度上提高效率，但这些技术都因破坏了执行流、进程/线程间的层次关系，又无法摆脱进程/线程模型的约束，无法实现所期望的目的。

学术界已经认识到了进程/线程模型的内在缺陷，为克服或弥补该缺陷所做的主要研究工作已有：

(1)CMU的mach研究组提出了续体(Continuations)的概念，以减少线程切换和堆栈的开销，并采用优化IPC以加快消息的传递。在一定程度上将进程间通讯同步化，减少了通讯开销。但续体只能用在内核中，而且只能在某些特殊的环境下才能实现优化，也无法满足分布式计算的性能需求。

(2)主动消息(Active Message)的提出旨在降低大型并行机中的通讯开销。其方法是将通讯过程和计算过程连接起来，以避免线程调度所带来的延迟、数据的缓存和拷贝。但这种方法受到如下限制：1)处理例程在运行的过程中不能阻塞；2)可能引起死锁；3)处理例程的运行时间不能过长，否则可能阻塞其他网络上发来的消息。

(3)跨地址空间调用已发展为微内核模型下的过程式IPC。其基本原理是：通过由服务进程提供调用点，客户程序可直接进入服务进程，从而可有效地降低线程模型所带来的系统开销。但为了维护线程模型不被破坏，必须付出的额外代价是：1)线程/进程的从属关系必须随着进出调用点而改变，以免破坏原有线程模型的语义。2)跨地址空间的同步调用只能通过上层协议的异步功能实现。这些代价不但给程序员带来困难，也不利于错误处理。

澳大利亚Adelaide大学和悉尼大学联合提出的Container/Loci概念取代了传统的线程概念，以Container为唯一代表数据存储的抽象、以Loci为执行的抽象。Container/Loci模型已抛弃了进程/线程模型中的很多内容，实现了存储和计算的分离，但他们仍停留在永久存储和单地址空间的研究上，而使用虚拟性的Loci，显然仍会影响系统效率。

发明内容

本发明的目的在于，提出一种更合理的新型操作系统，以克服当前操作系统发展遇到的障碍，解决其依赖的构造模型——进程/线程模型的内在缺陷所导致的系统在效率、实时性、结构灵活性等方面的限制。

本发明的基于服务体/执行流模型的操作系统，采用服务体/执行流结构，该结构由服务体和执行流两类机制构成；每个服务体均具有自己的服务体地址空间，服务体之间采用消息推动通信；所述执行流是物理CPU沿着指令计数器指示的指令执行顺序执行指令而形成的轨迹，该执行流是连续的；

所述服务体按照相同规范构造，包括功能代码、数据集合、端口以及端口所包含的若干小端口，用于实现操作系统中所有功能组件的功能，执行流只有通过小端口才能进入服务体；系统中其他系统软件和用户程序也以服务体形式加载到操作系统上；

所述服务体的端口均采用统一的规范设计，用于支持系统中各服务体之间的通信；

所述服务体中设置一个核心服务体，用于引导执行流通过服务体的小端口进入服务体并提供对服务体与执行流的管理、服务体之间通信的管理、中断与异常的处理以及并发控制基础服务。

本发明是以图4所示的服务体/执行流结构作为基础结构、以消息推动通信为关键技术、以一系列相关的具体构造方法为辅助方法而综合构成的操作系统构造方法。

所述操作系统中的服务体自底向上划分为基本机制层、服务层、运行环境层三个层次，所述基本机制层是系统运行的基础机制；所述服务层，用于提供系统主要的服务功能；所述运行环境层，用于提供用户程序的编程模型和运行环境。上述功能层次的划分用来指导操作系统的设计实现者进行系统功能组件服务体的分划和设计。

在所述运行环境层中，还可以构造模拟其他操作系统运行环境的服务体，用来将所述其他操作系统所支持的系统软件或用户程序引导、加入到本操作系统中运行。

所述服务体的端口对应于一个消息处理例程，该例程所能处理的所有消息接口的集合构成端口界面；所述消息接口，用于定义该消息特定的语义和接口参数信息的类型以及消息号。

所述服务体的端口界面有统一规范的定义；服务体的端口界面的标识由主版本号、次版本号和全局唯一标识符三部分组成，其中，主版本号和次版本号用以支持版本的升级和兼容。

所述服务体地址空间是多维的，包括基本空间和扩展空间；所述的基本空间包括私有段和共享段两个部分；所述服务体可以有多个扩展空间，用于分别加载不同的程序，以实现多地址空间的语义。

所述的服务体地址空间可实现单地址空间管理模式、分组单地址空间管理模式或/和私有多地址空间管理模式；

所述单地址空间管理模式，使不同服务体在基本空间和扩展空间的使用上分别占用不同的地址空间，如同在同一地址空间内分配，从而简单直接地实现了单地址空间管理模式。

所述分组单地址空间管理模式，将有共享数据行为的服务体划分在一组，组内按单地址模式进行空间管理。由于一个组内的服务体是有限的，因此可以在32位体系结构上实现。

所述私有多地址空间管理，使扩展空间为服务体所私有，对扩展空间按分页方式进行管理。因此，可以根据需要将当前页交换到后备存储器中，以优化系统内存的使用和提高效率。由于一个服务体可以拥有多个私有空间，因此可以使所管理数据的容量能够超过处理器字长对虚存空间的限制。

所述消息推动通信，通过将消息从源信息主体的地址空间直接推入目标通信主体的地址空间，实现通信主体之间的通信。

所述消息推动通信的通信方式包括同步连续通信方式、同步分离通信方式或/和异步通信方式；

所述同步连续通讯方式是指：源通信主体A的同步通信消息从自己的地址空间经由目的通信主体B的通信接口直接推入目的通信主体B的地址空间，该消息立即被目的通信主体B中的相应处理例程处理，处理完成后立即发送一条返回消息经由上述源通信主体A的发送该同步消息的通信接口返回至源通信主体A，继续执行源通信主体A的任务；

所述同步分离通信方式是指：源通信主体A的同步通信消息从自己的地址空间经由目的通信主体B的通信接口直接推入目的通信主体B的地址空间，同时在该消息中还指明第三通信主体C的一个通信接口作为应答接口，当目的通信主体B处理完所推入的消息后，执行流将通过上述应答接口进入所指明的第三通信主体C；所述第三通信主体也可以是源通信主体A；

所述异步通信方式是指：源通信主体A将消息经由目的通信主体B的通信接口推入目的通信主体B的地址空间后，执行流立即返回源通信主体A，目的通信主体B将在以后适当的时机再对该消息进行处理。

具体而言，上述服务体具有静态和持久的性质，它具有自己的地址空间，只有当执行流通过端口被引入服务体时，该服务体的程序才被执行，服务体具有通信功能，它通过消息推动方式达到与其他服务体通信目的；服务体的每一个端口对应了一个消息处理例程，而端口则是服务体与外界通信的唯一合法出/入口。因此，服务体间是相互隔离的，低耦合的；一个端口可以包括若干个小端口，小端口提供相应的消息例程运行时堆栈，并记录运行时所需的上下文相关信息。小端口数量决定了该服务体的并发度；服务体的端口是可重入的，因此，它允许高优先级的消息立即被处理。

上述执行流是连续的，从机器上电复位到关机中途不会被阻塞、挂起或中止，也不会与某个特定的地址空间绑定；执行流通过服务体的一个小端口进入服务体，执行该服务体的相应程序。当一个服务体需要调用另一个服务体的程序时，通过消息将执行流推入被调用的服务体，此时执行流就跨越地址空间边界流入被调用服务体。

上述核心服务体在逻辑上相当于微内核操作系统的内核，核心服务体与其他服务体的地位是平等的，因此不存在内核态的概念。

上述消息推动通信是指将消息从源信息主体的地址空间直接推入目的通信主体的地址空间通信的方式，如图5所示，每个通信主体拥有各自的地址空间和通信接口，通信接口中包含消息处理例程入口及相关信息；消息推动通信的通信方式包括同步连续通信、同步分离通信和异步通信三种通信方式；

1)同步连续通信方式，其通信步骤是：作为源通信主体的服务体A将同步通信消息从自己的地址空间经由作为目的通信主体的服务体B的通信接口直接推入服务体B的地址空间，该通信消息立即被服务体B中相应处理程序处理，处理完成后立即发送一个返回信息到服务体A，由服务体A发送前述同步消息的通信接口接收，如图6所示；

2)同步分离通信方式，其通信步骤为：在作为源通信主体的服务体A所发出的消息中，除了要指明作为目的通信主体的服务体B的通信接口之外，还需指明一个称为应答端口的某个服务体(如服务体C)的通信接口。当服务体A将消息通过指定的服务体B的通信接口推入服务体B的地址空间后，立即被服务体B的相应处理程序处理，处理完成后，由服务体B通过所指明的应答端口将执行流推入该应答端口所属的某一服务体(如服务体C)中，如图7所示；

3)异步通信方式，其通信步骤是：作为源通信主体的服务体A将同步通信消息从自己的地址空间经由作为目的通信主体的服务体B的通信接口推入服务体B的地址空间后，立即返回服务体A，服务体B将在以后适当的时机再对前述消息进行处理，如图8所示。

本发明的优点在于，本发明基于服务体/执行流结构提供了一种更合理的操作系统，其优点有：

①明显提高运行效率，对服务体而言：

●用同步的执行流作为系统计算行为的抽象，申请服务时执行流直接将消息带入目标服务体空间，避免了消息拷贝和进出队列的开销；

●在执行上，执行流直接激活目标服务体的小端口进入服务体，避免了采用线程时的睡眠、唤醒以及线程调度而带来的开销(调度开销在线程数量比较大的时候是很可观的)；在上下文保存方面，激活目标小端口不必恢复其任何寄存器，当执行流发送应答消息的时候也不必保存任何寄存器，整个过程只需保存和恢复系统的Preserve寄存器集合；

●当消息的发送方使用的是同步-分离机制的时候，整个过程甚至一个寄存器都不必保存和恢复，其效率与进程间通讯相比有极大的提高。我们在原型系统MiniCore性能测试也证明了这一点。

②降低系统资源的消耗

在进程/线程模型中，虽然线程是轻量级的调度单位，但仍占有可观的系统资源，这种资源主要是来自于内核堆栈以及与调度相关的一些资源。

在服务体模型中由于取消了进程/线程的抽象，每个服务体的小端口都有自己的堆栈，中断处理过程被模拟成向核心服务体发送一个消息，消息处理过程使用的是核心服务体服务端口的堆栈，其数量仅与系统内执行流的个数相关，而与包括系统规模在的内任何其它因素都没有关系。系统的所有部件都是平等的，没有内核空间的概念，不存在维护内核堆栈的问题，从而完全消除了所述进程/线程模型面临的困难。

③语义完备性维护与系统的健壮性方面的优势

在微内核模型中，线程通过消息队列来交换数据。为了保证模型的正确性，一个消息队列只允许一个线程具有接收权，其余线程只能拥有发送权。内核在运行过程需要对此进行检查和处理以保证语义的完备性。

在服务体模型中，该语义是自然的成立。因为一个端口对应于一个消息处理例程，仅有该处理例程才能处理传递给该端口的消息。因此在服务体模型中避免了不必要的检查开销，同时也避免了用户因为设计上的失误而引发的错误，增强了系统的健壮性。

④实时性有明显的提高

现有模型的线程之间仅能通过共享内存实现通讯，在消息的通知方面具有先天的缺陷，对处理异步发生的事件来说，线程模型往往会带来很大的处理时间延迟。

对于服务体而言，由于执行流的同步性，小端口是直接被激活的，所以启动时间微乎其微；当一个服务体请求其他服务体提供的服务时，执行流直接流入目标服务体，通过设置小端口选项可以使执行流的优先级保持不变，此时高优先级事务的请求优先得到了处理，避免了服务器优先级设置而带来的优先级反转等问题；同样由于执行流直接通过小端口进入服务体，是同步的而且是可重入的，因此当更高优先级的事件被激活时，对应的一个空闲小端口立即被激活，不会因为该端口正在处理低优先级的事件而造成高优先级事件被滞后处理。由于服务体在实时性的优势，非常适合应用在对实时性有严格要求的场合。

⑤有效支持分布式处理

在基于进程/线程模型的分布式系统中，为了实现资源的优化使用或是为了提高系统的冗余度所采取的技术是进程迁移。进程迁移的困难在于进程/线程模型中对数据的计算和存储是紧密结合的，不能独立存在。所以必须将进程从源结点完全迁往目标结点，并在目标结点重新构造整个进程空间的内容，整个过程的开销是很大的。

而服务体/执行流模型将计算能力和数据存储能力进行了分离，从而可以更加容易的实现分布式的处理。由于服务体和执行流彼此独立，因此一个服务体可以同时存在于多个结点上。当计算发生迁移的时候，服务体已经在目标结点了，只要通过对象管理器更新相应的端口权利即可将所有的服务推到新的结点中。服务体使用新结点的执行流进行工作，初始的时候可能会有发生数据的远程调页，随着服务体不断的运行，Cache管理器会逐渐将其工作集页面缓冲在本地，其运行效率将很快达到正常水平，从而对分布式计算提供有效地支持。

⑥对持久性存储的支持

在进程/线程模型中，进程空间的生命期和进程的执行能力是联系在一起的，因此进程空间的本质是临时性的，这种临时性为系统实现持久存储、分布式计算以及高可靠性都带来很大的困难。

在服务体模型中，服务体作为数据存储的基本抽象，它的存在不依赖于执行流，从本质上来说服务体具有持久性。因此，实现持久化更简洁更高效。

此外，服务体模型将单地址空间技术与私有多地址空间技术结合，为数据共享和数据存储提供了高效的实现支撑，可以更自然、更有效的实现数据查询和更新。由此带来的潜在优势是巨大的。在服务体模型的基础上，很容易构造出新型的与操作系统真正融合的、高效的数据库管理系统服务体。

⑦对主动网络的支持

对于进程/线程模型来说，其抽象的是若干个虚拟的CPU。这种抽象决定了以进程作为网络的接收端只能从网络节点上去“拉”数据，对于发送方“推”过来的数据只能先放在一个缓冲区中，然后由接受方再从缓冲区中将数据“拉”到自己的进程空间进行处理。因此采用进程/线程模型只能在“拉”的基础上实现“推”，无法完全实现“推”的概念。这种以“拉”为“推”的实现方式阻碍了主动网络优越性的发挥。

在服务体模型中，由于端口实际上代表了一段处理例程，因此对处理“推”机制有着天然的优势，可以完全克服进程模型的这种缺陷。由于服务体模型在通讯机制和消息处理方面与主动网络的思想在本质上是一致的，服务体之间的消息传递过程实际上就是一个“推”的过程，由执行流将消息通过小端口直接带入到目标服务体中。以服务体为基础实现主动网络可以看成是将服务体的这种消息传递的手段推广到网络报文的传递和处理，因此，可以获得更好的效率以及更加自然、和谐的系统体系结构。

⑧对操作系统可裁剪性与开放性的支持

服务体/执行流模型则从根本上打破了进程/线程模型的约束，服务体各部分之间良好的隔离性和模块化的结构特征，可以充分支持操作系统的剪裁和扩充。尤其在服务体模型中没有核心态的概念，所有的服务体之间是平等的。即使是核心服务体所提供的管理服务，也是可以由其他服务体所替换和扩充的，因此具有良好的灵活性和可重构性，从而具有很好的开放性。此外，新颖的服务体/执行流模型的同步通讯机制可以充分支持集群间的并行控制，以及分布式环境的分布计算服务体的唯一性和网络间透明传播。

综上所述，执行流是CPU运算能力的最原始的抽象，它像CPU推动的传送带沿着PC寄存器给出的指令序列前进，形成一条指令执行的轨迹，它描述的是一个连续的、实在的物理CPU运行过程，从CPU的上电复位到关机，中途不会像虚拟CPU那样被阻塞、挂起和停止，也不会于某个特定的地址空间绑定，当执行流流过某个服务体的代码序列时，该服务体的程序被执行，当一个服务体需要调用另一个服务体时，通过消息将执行流引向被调用服务体，此时执行流就会跨越地址边界在两个服务体间流动，行为简单而又自然，而不必向线程切换那样，将物理CPU在两个虚拟CPU间切换。

核心服务体是系统的一个关键组件，它通过服务体间的通信机制和并发调度来控制和管理执行流和服务体，主要提供服务体间通信机制、执行流/服务体的管理、中断和异常等基础服务，实现多个服务体间的并发控制。一个CPU提供一个执行流，多个CPU提供多个执行流，核心服务体具有识别和调度单流并发，多流并行的能力，从而可以有效地支持并行与分布式计算。

由于服务体模型将运行模型和存储模型分离，而且摒弃了虚拟CPU的概念，因此可以采用同步消息传递作为服务体间的通信方式，从而可以有效提高系统的效率和支持主动网络，同时从构造原理上保证了系统的可扩展性和可维护性。

因此，本发明的执行流/服务体模型在实时性、多处理机支持、系统资源的消耗、语义完备性的维护、对分布式处理和对主动网络的支持等方面，比现有的进程/线程模型具有明显优势。

附图说明

图1是现有技术的进程/线程模型示意图。

图2是现有技术的单一大内核操作系统构造示意图。

图3是现有技术的微内核操作系统构造示意图。

图4是本发明操作系统的服务体/执行流结构的示意图。

图5是本发明操作系统的基于消息推动的通信的示意图。

图6是本发明消息推动通信的同步连续通信方式的示意图。

图7是本发明消息推动通信的同步分离通信方式的示意图。

图8是本发明消息推动通信的异步通信方式的示意图。

图9是本发明操作系统的服务体端口和小端口构造的示意图。

图10是本发明服务体多维地址空间示意图。

图11是本发明单地址空间管理模式的示意图。

图12是本发明分组单地址空间管理模式的示意图。

图13是本发明私有多地址空间管理模式的示意图。

图14是本发明文件系统的持久化的示意图。

图15是本发明文件系统持久化的提交算法的示意图。

图16是本发明操作系统总体结构示意图。

图17是本发明核心服务体模块和结构示意图。

图18是本发明对象管理服务体结构示意图。

图19是本发明虚存管理子系统结构的示意图。

图20是本发明I/O管理服务体对分层驱动的管理的示意图。

图21是本发明堆叠文件系统的工作过程的示意图。

图22是本发明Linux运行环境服务体结构示意图。

具体实施方式

下面就对本发明具体实施实例进行详细说明。

当依据服务体/执行流结构和利用消息推动通信技术来构造操作系统时，还需要提供下述具体的构造方法作为辅助方法。

A、操作系统中的所有的功能组件都以服务体的形式出现。

操作系统运行时执行流在消息的引导下进入相应的服务体执行所需的程序。因此系统中所有的服务体必须都以统一规范的方法来构造。该构造方法的关键在于服务体通信接口的规范化设计，如图9所示，具体说明如下：

服务体提供若干个端口作为其通信接口。端口定义了服务体的合法入口，对应于服务体提供的服务例程以及相应的描述信息；

每个上述端口包含一个或多个小端口，小端口记录了服务例程运行时堆栈和与运行相关的其他上下文信息。小端口的数量决定了该端口的并发度；

执行流只能从端口的某个小端口进入服务体，并根据端口和小端口中的信息进行状态和资源的切换。

B、多维地址空间构造方法：该方法所组织的服务体的地址空间划分或基本空间和扩展空间两个部分，基本空间又划分为私有段和共享段两部分，如图10所示；不同服务体的共享段之间互不重叠，具有互斥性；私有段则由其所在虚拟空间的拥有者根据需要来独立分配；一个服务体的地址空间可以拥有一个或多个扩展空间，每个扩展空间具有唯一的名字。由上述方法构造的地址空间是多维的。本发明利用上述的多维地址空间构造方法来构造系统中所有服务体的地址空间。

C、服务体端口界面定义规范：一个服务体端口对应于一个消息处理例程，该例程所能处理的所有消息的接口的集合称为端口界面。操作系统的设计者必须制定服务体端口界面的规范定义来约束服务体的实现者和使用者；每个消息接口定义了该消息特定的语义和接口参数等信息的类型和消息的名字(消息号)；服务体端口界面由主版本号、次版本号和全局唯一标识符UUID(Universal Unique Identifier)三部分标识。主版本号和次版本号用以支持版本的升级和兼容，UUID在分布式系统中具有全局唯一性。

D、操作系统构造框架。利用本发明的方法来构造操作系统时必须按该构造框架来设计操作系统，该框架包括以下规则和约定：

以服务体作为操作系统得基本组成单位，所有操作系统功能组件、系统软件和用户程序都必须以服务体的形式加入到系统中；

操作系统中所有的服务体都必须按统一的服务体构造方法、统一的地址空间构造方法和统一的服务体端口界面规范来设计；

操作系统的功能组件自底向上划分为基本机制层、服务层和运行环境层三个层次。基本机制层提供系统运行所依赖的基础机制；服务层提供系统主要的服务功能；运行环境提供用户程序的编程模型和运行环境。上述功能层次的划分用来指导操作系统的设计实现者进行系统功能组件服务体的分划和设计；

本操作系统直接支持的系统软件和用户程序都以服务体的形式加载到操作系统上；依赖于其它运行环境的系统软件和用户程序则加载到相应的运行环境上。

当操作系统扩充功能时，需要将所扩充的功能按上述统一规范组织成服务体。加入到操作系统中，系统的基本机制层提供服务体注册/撤销、动态加载和在线升级等功能。

E、三种可任选的地址空间管理模式：

单地址空间管理模式。使不同的服务体的基本空间的共享段占用不同的地址空间，如同在统一地址空间内进行分配，因此在基于服务体/执行流结构的操作系统中可以简单而直接地实现单地址空间管理模式，如图11所示；

分组单地址空间管理模式。将有数据共享行为的服务体划分在一组，组内采用单地址模式进行空间管理，组间则采用多地址模式进行空间管理，如图12所示。分组单地址空间管理模式既可在32位CPU计算平台上实现，又可具备单地址模式的主要优点，如可支持复杂数据结构的共享。这种方式在嵌入式应用中尤为实用；

私有多地址空间管理模式：如图13所示，该模式将服务体私有的扩展空间分页管理，可按需要与后备存储器交换以优化内存的使用；一个服务体的地址空间可以拥有多个私有空间，从而可使其所管理的数据的容量超过处理器字长对虚存空间的限制。使用该模式时可将大的私有数据和运行库加载到扩展空间中，而把对效率有特别意义的需共享的数据加载到基本空间中。

F、文件系统的持久化方法：通过在磁盘上为文件系统建立影子区域，如图14所示，并提供严格保持一致的提交算法，如图15所示，便可实现文件系统的持久化，从而为实现操作系统的持久性奠定了基础。

基于消息推动的通讯机制在执行流/服务体模型中的应用：基于消息推动的服务体间通信机制以服务体为通信主体，以端口/小端口为通信接口，提供同步连续、同步分离和异步通讯方式。执行流将消息从源服务体A经由目标服务体B的端口推入服务体B，并进入B的端口的消息处理程序处理该消息。在这里，消息是有类型数据的集合，具有确定的格式，由消息头部、数据描述区和在线数据区三部分组成，大小为一个物理页。(1)消息头部：定长，指明消息的类型、数据的个数、目的/应答端口等信息；(2)数据描述区：为每个数据提供一个数据描述条目，数据描述条目使用类型域指明数据的类型如在线数据类型；(3)在线数据区：在线数据就是存储在在线数据区的数据，对于在线数据，数据描述条目中使用偏移量和存储量来指明在线数据的地址和大小。执行流/服务体模型只提供一个消息推动原语实现同步连续、同步分离和异步的通讯方式，其中：

同步连续方式：源服务体仅仅在消息中指定目标服务体端口，由消息推动原语隐含地为源服务体生成一个应答端口，执行流通过指定的目标端口的某个空闲小端口进入相应的目标服务体，由目标端口的消息处理程序处理该消息，消息处理结束后从上述应答端口返回源服务体。

同步分离方式：在源服务体A所发出的消息中，除了要指明目标服务体B的端口之外，还需指明某个服务体的端口作为应答端口。当服务体A将消息通过目标端口推入服务体B的地址空间后，立即被服务体B的相应消息处理程序处理，处理完成后，由服务体B通过上述消息指明的应答端口将执行流推入该应答端口所属的服务体中；

异步方式：消息被绑定到目标服务体端口的一个空闲小端口上，同时该小端口被挂到端口调度队列中，执行流继而返回源服务体继续执行，而不是立刻通过该小端口进入目标服务体完成消息的处理。核心服务体会根据其优先级通过端口调度机制处理该被绑定的异步消息。

多维地址空间在执行流/服务体结构的操作系统中的应用：服务体地址空间采用多维地址空间，一个服务体只有一个基本空间，但是可以根据需要拥有一个或多个扩展空间。扩展空间位于地址空间的低端，基本空间位于地址空间的高端。基本空间的共享段位于基本空间的高端，作为系统资源统一分配，具有互斥性。也就是说，如果某个服务体申请了基本空间共享段的一段内存，则其他服务体就不可能再申请到分配给该地址段的内存了。不同服务体在基本空间共享段的使用上分别占用不同的地址区间，互不重叠，如同在同一个地址空间内分配一样。而基本空间私有段的分配则完全独立于其他服务体，每个服务体都可以根据需要使用这段空间，不同的服务体之间不具有互斥性。

基本空间共享段互斥分配的特性使得共享段中的内容很容易映射到另一个服务体中而不必改变映射地址：因为目标地址区间必然是空闲的。根据这个特点可以将运行时刻需要与其他服务体共享的复杂数据结构(包括图、树、链表等)以及代码(代码也可以理解成一种复杂的数据结构)加载到基本空间共享段中，并在不同的服务体间有效的共享这些数据和代码。在基于消息推动的服务体间通讯中，可以使用映射机制直接将消息或数据映射到目标服务体空间中，以减少消息拷贝、降低通讯开销。

消息界面技术在执行流/服务体结构的操作系统中的应用：服务体的每个端口可以处理若干个消息，使用消息界面技术对端口能够处理的消息进行规范化定义，使用消息界面的版本管理对服务体或端口进行版本升级的管理。

使用本专利设计并实现操作系统：

a)如图16所示的操作系统总的体系结构，划分为服务层和运行环境层三个层次。其中，

基本机制层提供系统运行所依赖的基础机制，包括核心服务体、对象管理服务体、内存管理子系统、IO管理子系统、权能服务体和安全服务体。内存管理子系统实现系统的存储模型，提供物理内存管理和虚拟内存管理；IO管理子系统实现系统的驱动程序和设备管理模型，实现IO设备管理和文件系统管理；对象管理服务体实现对系统中的各种对象、端口的全局统一管理；核心服务体实现底层系统机制，提供服务体/执行流模型的抽象，包括端口调度、服务体管理、消息传递等；权能服务体和安全服务体实现对系统的安全管理。

服务层提供一些基本的系统服务功能，包括Cache管理服务体、文件系统服务体、驱动程序服务体、网络服务体、网络协议驱动服务体以及GUI服务体等。

运行环境层为用户提供编程模型，提供用户程序的运行环境，一部分用于实现对其他操作系统所支持的二进制应用程序的兼容，另一部分用于提供面向本操作系统的用户编程环境。

b)系统功能组件服务体的设计：

如图17所示的核心服务体，提供了底层基础控制机制，如中断/异常管理、同步机制、服务体间通信机制、端口管理和小端口调度等。此外，核心服务体对服务体进行管理，因此又扮演了服务体管理器的角色。核心服务体提供的服务体间通信的安全控制是实现系统安全性的基础机制，也正是通过服务体间通信机制实现了对象服务的统一的、强制性的访问控制。

如图18所示的对象管理服务体，统一维护系统中的各种对象或端口，例如文件对象、内存对象等，提供一个统一机制实现服务的注册、查询等操作。为其它服务体提供统一的对象管理服务，如创建对象、返回对象的句柄，扮演了名字服务器的角色。在服务体模型中，端口、服务和对象是等价的概念，使用对象管理服务体统一控制对对象的访问。每个服务体提供一定的服务，每种服务等价为一个对象，通过服务体的端口对外提供访问接口。对象管理服务体通过控制主体能够对端口发送的消息界面控制主体能够对端口代表的对象进行的访问操作。对象管理服务体统一管理本地和远程的各种对象，并将这些对象组织成树状层次。

内存管理子系统由物理存储管理服务体和虚存管理子系统两个部分组成。

物理存储管理服务体主要提供物理页面的分配、回收和查询等服务。该服务体在基本空间的共享段预留了相应尺寸的空间，以映射所有可分配的物理内存供该服务体使用。同时，将空闲的物理内存按其存储尺寸组织成不同的空闲链表，以支持高效的查询服务。

虚存管理子系统包括虚存管理服务体、Pager服务体和Memory服务体，并定义了与虚存管理相关的四个对象：space对象代表服务体的虚存空间；pager对象负责数据的管理；memory对象按照用户的访问权限提供pager对象的不同视图；cache对象则是对pager对象中的数据进行缓冲。这四个对象之间的关系如图19所示。

Pager服务体负责页面数据的管理，包括：调入一个页面、写回并从cache对象中移出一个页面、写回修改过的页面数据以及设定、修改页面权限等。

Memory服务体负责memory对象的管理，包括：权限检查、确定与memory对象相关联的pager对象、根据权限设定memory视图，以及针对基本空间共享所提供如下四种服务：①将一个memory对象映射到共享段中；②根据权限提供memory对象的共享服务；③分配和④释放服务体的保留空间。

虚存管理服务体VMSB则主要管理cache对象和space对象。该服务体在物理内存管理服务体所提供服务的基础上，对memory对象和pager对象之间的交互提供映射、缓冲和共享等虚存服务。

I/O管理服务体：实现各个设备和驱动程序之间的管理与协调等功能。为文件系统和驱动程序提供了统一的基础机制，以支持各种文件系统，从而简化文件系统的设计，同时提供了相当灵活的驱动程序模型，为可堆叠的文件系统和分层的驱动程序提供了强有力的支持。IO管理服务体使用设备对象和驱动程序对象来表示系统中的所有设备和驱动程序。IO管理服务体支持的分层驱动结构图和可堆叠文件系统结构图，分别如图20和21所示。

Cache管理服务体：为了提高IO的效率，系统中单独提供Cache管理服务体，它与IO管理服务体、内存管理服务体和对象管理服务体共同协作，为各种文件系统和驱动程序的IO请求提供统一的缓存机制。

文件系统服务体：实现各种具体的文件系统驱动，例如FAT、EXT2、NTFS等。并且如果需要可以实现支持持久存储的文件系统。

如图22所示的Linux运行环境服务体为用户程序提供Linux运行环境，为用户提供与Linux相同的编程模型，同时实现了Linux应用程序的二进制兼容，可以重用已有的Linux应用程序，利用已有投资。Linux运行环境用端口来实现Linux的进程/线程抽象和捕获Linux应用程序的系统调用，同时利用服务体的扩展空间来实现Linux的进程地址空间。

服务体运行环境：提供一组规范、标准和编程环境，供用户实现自己的服务体(用户服务体)，这也是在服务体/执行流模型中设计用户程序的标准方法，使用这种方式编写的用户程序能充分发挥服务体/执行流模型的优势，达到最好的效率。

Claims (9)

1、一种基于服务体/执行流模型的操作系统，其特征在于：该操作系统采用服务体/执行流结构，该结构由服务体和执行流两类机制构成；每个服务体均具有自己的服务体地址空间，服务体之间采用消息推动通信；所述执行流是物理CPU沿着指令计数器指示的指令执行顺序执行指令而形成的轨迹，该执行流是连续的；

所述服务体按照相同规范构造，包括功能代码、数据集合、端口以及端口所包含的若干小端口，用于实现操作系统中所有功能组件的功能，执行流只有通过小端口才能进入服务体；系统中其他系统软件和用户程序也以服务体形式加载到操作系统上；

所述服务体的端口均采用统一的规范设计，用于支持系统中各服务体之间的通信；

所述服务体中设置一个核心服务体，用于引导执行流通过服务体的小端口进入服务体并提供对服务体与执行流的管理、服务体之间通信的管理、中断与异常的处理以及并发控制基础服务。

2、按照权利要求1所述的操作系统，其特征在于：所述操作系统中的服务体自底向上划分为基本机制层、服务层、运行环境层三个层次，所述基本机制层是系统运行的基础机制；所述服务层，用于提供系统主要的服务功能；所述运行环境层，用于提供用户程序的编程模型和运行环境。

3、按照权利要求1或2所述的操作系统，其特征在于：在所述运行环境层中，还可以构造模拟其他操作系统运行环境的服务体，用来将所述其他操作系统所支持的系统软件或用户程序引导、加入到本操作系统中运行。

4、按照权利要求1所述的操作系统，其特征在于，所述服务体的端口对应于一个消息处理例程，该例程所能处理的所有消息接口的集合构成端口界面；所述消息接口，用于定义该消息特定的语义和接口参数信息的类型以及消息号。

5、按照权利要求4所述的操作系统，其特征在于：所述服务体的端口界面有统一规范的定义；服务体的端口界面的标识由主版本号、次版本号和全局唯一标识符三部分组成，其中，主版本号和次版本号用以支持版本的升级和兼容。

6、按照权利要求1所述的操作系统，其特征在于，所述服务体地址空间是多维的，包括基本空间和扩展空间；

所述的基本空间包括私有段和共享段两个部分；

所述服务体可以有多个扩展空间，用于分别加载不同的程序，以实现多地址空间的语义。

7、按照权利要求6所述的操作系统，其特征在于，所述的服务体地址空间可实现单地址空间管理模式、分组单地址空间管理模式或/和私有多地址空间管理模式；

所述单地址空间管理模式，使不同服务体在基本空间和扩展空间的使用上分别占用不同的地址空间，实现在同一地址空间内的使用分配；

所述分组单地址空间管理模式，将有共享数据行为的服务体划分在一组，组内按单地址模式进行空间管理；

所述私有多地址空间管理，使扩展空间为服务体所私有，对扩展空间按分页方式进行管理。

8、按照权利要求1所述的操作系统，其特征在于：所述消息推动通信，通过将消息从源信息主体的地址空间直接推入目标通信主体的地址空间，实现通信主体之间的通信。

9、按照权利要求1或8所述的操作系统，其特征在于：所述消息推动通信的通信方式包括同步连续通信方式、同步分离通信方式或/和异步通信方式；

所述同步连续通讯方式是指：源通信主体(A)的同步通信消息从自己的地址空间经由目的通信主体(B)的通信接口直接推入目的通信主体(B)的地址空间，该消息立即被目的通信主体(B)中的相应处理例程处理，处理完成后立即发送一条返回消息经由上述源通信主体(A)的发送该同步消息的通信接口返回至源通信主体(A)，继续执行源通信主体(A)的任务；

所述同步分离通信方式是指：源通信主体(A)的同步通信消息从自己的地址空间经由目的通信主体(B)的通信接口直接推入目的通信主体(B)的地址空间，同时在该消息中还指明第三通信主体(C)的一个通信接口作为应答接口，当目的通信主体(B)处理完所推入的消息后，执行流将通过上述应答接口进入所指明的第三通信主体(C)；所述第三通信主体也可以是源通信主体(A)；

所述异步通信方式是指：源通信主体(A)将消息经由目的通信主体(B)的通信接口推入目的通信主体(B)的地址空间后，执行流立即返回源通信主体(A)，目的通信主体(B)将在以后适当的时机再对该消息进行处理。

Images