CN121166331A - 一种系统服务的调用方法及相关装置 - Google Patents

Abstract

本申请提供一种系统服务的调用方法，应用于微内核架构下的内核。在该系统服务的调用方法中，当内核获取到线程首次调用某个系统服务的请求时，内核与该系统服务的执行实体建立连接并调用执行实体来处理请求，在执行实体完成请求的处理后，内核并不清理与执行实体之间的连接而是将执行实体的状态更新为托管状态，从而保留线程与该执行实体之间的对应关系。这样，在线程下次继续调用该系统服务时，内核则可以基于保留的对应关系以及与执行实体之间的连接，快速地调用处于托管状态的执行实体来处理线程的请求，从而提高线程调用系统服务的效率。

Description

一种系统服务的调用方法及相关装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种系统服务的调用方法及相关装置。

背景技术

微内核(micro kernel)架构和单一内核(monolithic kernel)架构是目前操作系统内核架构的两种主要形式。相较于采用内核来提供所有操作系统功能的单一内核架构，微内核架构遵循最小化原则，内核只提供最必要的功能(例如中断管理、异常管理、内存映射管理、进程间通信等功能)，大量的功能(例如进程管理、内存管理、文件系统等功能)则依靠各个系统服务来提供。

由于微内核架构将大部分的系统服务与内核隔离开，因此在系统服务出现错误时也不会影响到整个操作系统的稳定性。并且，与内核隔离开的系统服务通常是在非特权空间下实现，使得系统服务能够独立开发、测试和更新，因此在微内核架构下能够确保操作系统具有较高的可维护性和安全性。

但是，由于微内核架构下大部分的系统服务与内核是隔离的，因此应用程序在通过内核调用系统服务时往往需要执行较多的步骤，导致应用程序调用系统服务的效率较低。

发明内容

本申请提供一种系统服务的调用方法，能够提高线程调用系统服务的效率。

本申请第一方面提供一种系统服务的调用方法，该方法应用于微内核架构下的内核。具体地，该系统服务的调用方法包括：在获取到来自于第一线程的第一调用请求时，内核通过与第一系统服务的执行实体建立连接来调用执行实体处理第一调用请求，并记录第一线程与执行实体之间的对应关系，以便于在获取到执行实体所返回的处理结果时能够将处理结果准确地返回给第一线程。其中，第一调用请求用于请求调用第一系统服务。

在执行实体完成第一调用请求的处理并返回处理结果时，内核将处理结果返回给第一线程且将执行实体的状态更新为托管状态。其中，处于托管状态下的执行实体与内核之间的连接不会被清理。即，内核并不会清理内核与执行实体之间的连接，也不会释放执行实体至资源池中，而是将执行实体的状态更新为托管状态。处于托管状态下的执行实体与内核之间的连接不会被清理，而是会一直保持。在执行实体处于托管状态的情况下，内核将会托管执行实体且保留第一线程与执行实体之间的对应关系，从而使得执行实体只能够被第一线程所调用，而不能够再被其他的线程调用。

其次，在获取到来自于第一线程的第二调用请求时，内核基于对应关系和连接调用执行实体来处理第二调用请求，第二调用请求用于请求调用第一系统服务。即，内核可以基于所保留的第一线程与执行实体之间的对应关系，确定第一线程当前对应有处于托管状态的第一系统服务的执行实体。这样，内核则不需要再查找第一系统服务的其他执行实体来处理第二调用请求，而是基于内核与处于托管状态的执行实体之间的连接直接调用执行实体来处理第二调用请求，从而使得内核以接近直接调用的方式调用执行实体，而非以进程间通信(Inter Process Communication，IPC)的方式调用执行实体。

本方案中，在内核获取到线程首次调用某个系统服务的请求时，内核与该系统服务的执行实体建立连接并调用执行实体来处理请求，在执行实体完成请求的处理后，内核并不清理与执行实体之间的连接而是将执行实体的状态更新为托管状态，从而保留线程与该执行实体之间的对应关系。这样，在线程下次继续调用该系统服务时，内核则可以基于保留的对应关系以及与执行实体之间的连接，快速地调用处于托管状态的执行实体来处理线程的请求，从而使得内核以接近直接调用的方式调用执行实体，而非以IPC的方式调用执行实体，提高线程调用系统服务的效率。

在一种可能的实现方式中，在将处理结果返回给第一线程后，内核可以将第一线程的状态更新为对应有托管实体状态，其中对应有托管实体状态用于指示第一线程具有对应的被托管的执行实体。这样，在获取到来自于第一线程的第二调用请求时，基于第一线程的状态(即对应有托管实体状态)，内核可以是快速地确定当前需要调用处于托管状态的执行实体来处理第二调用请求，而不需要查找或创建其他的执行实体来处理第二调用请求。

本方案中，通过将第一线程的状态更新为对应有托管实体状态，可以使得内核在获取到来自于第一线程的调用请求时，快速地判断第一线程当前是否具有托管中的执行实体，进而确定后续是直接调用托管的执行实体还是查找或创建其他的执行实体，从而提高系统服务的调用效率。

在一种可能的实现方式中，在获取到来自于第一线程的第三调用请求时，内核清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第三调用请求用于请求调用第二系统服务，处于休眠等待状态下的执行实体能够被其他的线程调用。

然后，内核通过与第二系统服务的执行实体建立连接来调用第二系统服务的执行实体处理第三调用请求，并记录第一线程与第二系统服务的执行实体之间的对应关系。即，针对于调用第二系统服务的第三调用请求，由于第一线程当前并没有对应有处于托管状态的且属于第二系统服务的执行实体，因此内核需要查找或创建一个第二系统服务的执行实体来处理第三调用请求。

本方案中，在线程对应有某一系统服务的且处于托管状态的执行实体的情况下，当线程请求调用另一个系统服务时，内核则触发清理与处于托管状态的执行实体之间的连接且将该执行实体释放，并且基于新的调用请求来与另一个系统服务的执行实体建立连接以调用另一个系统服务的执行实体来处理线程的调用请求，保证系统服务的正常调用，且避免同一个线程对应有过多的处于托管状态的执行实体而造成资源浪费。

在一种可能的实现方式中，在获取到来自于第一线程的第四调用请求时，若执行实体不可用，内核则清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第四调用请求用于请求调用第一系统服务。

然后，通过与第一系统服务的其他执行实体建立连接来调用其他执行实体处理第四调用请求，并记录第一线程与其他执行实体之间的对应关系。

也就是说，如果如果处于托管状态的某一系统服务的执行实体不可用时，内核可以释放这个处于托管状态的执行实体，并且与同一系统服务下的其他执行实体建立连接并调用其他执行实体来处理线程的调用请求，以便于保证线程所发送的调用请求能够被正常处理，确保系统服务的正常调用。

在第一系统服务的执行实体不可用的情况下，由于通知该执行实体不可在当前处理器上继续执行的流程开销与重新调用新的执行实体的流程开销接近，因此本方案中是释放托管状态下的执行实体并且基于调用请求重新调用新的执行实体来处理，从而尽可能减少对现有技术的改动，提高本方案的可实现性和兼容性。

在一种可能的实现方式中，第一线程在同一时间对应于一个被托管的执行实体。也就是说，在同一时间下，内核只会为第一线程托管一个执行实体，而不会为第一线程托管多个不同的执行实体。

本方案中，通过设定内核在同一时间下仅为同一个线程托管一个执行实体，能够保证在具有较高的系统服务调用效率的同时，尽可能地降低系统复杂度以及系统所占据的处理资源。

在一种可能的实现方式中，第一系统服务处于特权态或非特权态。

在一种可能的实现方式中，执行实体与内核之间的连接为进程间通信(InterProcess Communication，IPC)连接。

在一种可能的实现方式中，第一系统服务用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务。

本申请第二方面提供一种系统服务的调用装置，该系统服务的调用装置应用于实现微内核架构下的内核，该系统服务的调用装置包括：收发模块和处理模块；

在收发模块获取到来自于第一线程的第一调用请求时，处理模块用于通过与第一系统服务的执行实体建立连接来调用执行实体处理第一调用请求，并记录第一线程与执行实体之间的对应关系，其中第一调用请求用于请求调用第一系统服务；

在执行实体返回处理结果时，收发模块用于将处理结果返回给第一线程且处理模块还用于将执行实体的状态更新为托管状态，其中处于托管状态下的执行实体与内核之间的连接不会被清理；

在收发模块获取到来自于第一线程的第二调用请求时，处理模块还用于基于对应关系和连接调用执行实体来处理第二调用请求，第二调用请求用于请求调用第一系统服务。

在一种可能的实现方式中，在收发模块将处理结果返回给第一线程后，处理模块还用于将第一线程的状态更新为对应有托管实体状态，对应有托管实体状态用于指示第一线程具有对应的被托管的执行实体；

在收发模块获取到来自于第一线程的第二调用请求时，处理模块还用于基于第一线程的状态，确定调用处于托管状态的执行实体来处理第二调用请求。

在一种可能的实现方式中，在收发模块获取到来自于第一线程的第三调用请求时，处理模块还用于清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第三调用请求用于请求调用第二系统服务，处于休眠等待状态下的执行实体能够被其他的线程调用；

处理模块还用于通过与第二系统服务的执行实体建立连接来调用第二系统服务的执行实体处理第三调用请求，并记录第一线程与第二系统服务的执行实体之间的对应关系。

在一种可能的实现方式中，在收发模块获取到来自于第一线程的第四调用请求时，若执行实体不可用，处理模块还用于清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第四调用请求用于请求调用第一系统服务；

处理模块还用于通过与第一系统服务的其他执行实体建立连接来调用其他执行实体处理第四调用请求，并记录第一线程与其他执行实体之间的对应关系。

在一种可能的实现方式中，第一线程在同一时间对应于一个被托管的执行实体。

在一种可能的实现方式中，第一系统服务处于特权态或非特权态。

在一种可能的实现方式中，执行实体与内核之间的连接为IPC连接。

在一种可能的实现方式中，第一系统服务用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务。

本申请第三方面提供一种系统服务的调用装置，可以包括处理器，处理器和存储器耦合，存储器存储有程序指令，当存储器存储的程序指令被处理器执行时实现上述第一方面或第一方面任一实现方式的方法。对于处理器执行第一方面的各个可能实现方式中的步骤，具体均可以参阅第一方面，此处不再赘述。

本申请第四方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面任一实现方式的方法。

本申请第五方面提供了一种电路系统，电路系统包括处理电路，处理电路配置为执行上述第一方面任一实现方式的方法。

本申请第六方面提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面任一实现方式的方法。

本申请第七方面提供了一种芯片系统，该芯片系统包括处理器，用于支持服务器实现上述第一方面任一实现方式中所涉及的功能，例如，处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，芯片系统还包括存储器，存储器，用于保存服务器必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。

上述第二方面至第七方面的有益效果可以参考上述第一方面的介绍，在此不再赘述。

附图说明

图1为相关技术的一种单一内核架构和微内核架构下应用程序调用系统服务的对比示意图；

图2为本申请提供的一种系统架构的示意图；

图3为本申请提供的一种执行设备101的结构示意图；

图4为本申请提供的一种系统服务的调用方法的流程示意图；

图5为本申请提供的一种系统服务的调用方法的应用场景示意图；

图6为本申请提供的一种微内核架构下线程调用系统服务的对比示意图；

图7为本申请提供的一种线程调用系统服务的流程示意图；

图8为本申请提供的一种线程在不同情况下调用系统服务的流程示意图；

图9为本申请提供的一种线程状态机和系统服务的执行实体的状态机的示意图；

图10为本申请提供的一种线程、内核与执行实体之间的关系示意图；

图11为本申请提供的一种系统服务的调用装置的结构示意图；

图12为本申请提供的一种电子设备的结构示意图；

图13为本申请提供的一种计算机可读存储介质的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于理解，以下先介绍本申请实施例涉及的一些技术术语。

(1)微内核架构

微内核架构是操作系统的一种内核架构。微内核架构的典型特征，内核仅保留最基本和核心的操作系统功能(例如中断管理、异常管理、内存映射管理、进程间通信等功能)，其余的功能(例如进程管理、内存管理、文件系统等功能)则以系统服务的方式实现。

(2)单一内核架构

单一内核架构是操作系统的一种内核架构。相较于微内核架构，单一内核架构的典型特征是操作系统的所有服务(如进程管理、内存管理、文件系统、设备驱动、网络协议等)都运行在同一空间同一特权态。

(3)系统服务

系统服务是指执行指定系统功能的程序、例程或进程，以便支持其他程序来获取系统功能。在微内核系统中，一个系统服务通常负责提供一个具体的功能(如进程管理、内存管理、文件系统、设备驱动、网络协议等)，系统服务通常与微内核本身位于不同的特权态。

(4)执行实体

执行实体是指在系统服务中为一次用户调用提供服务的对象。一般来说，执行实体会包括一个位于系统服务的用户栈以及位于内核中的控制信息。

(5)特权态

特权态是指是操作系统的管理程序运行时的状态，具有较高的特权级别。具体来说，如果一个应用程序运行在特权态，该应用程序就可以访问计算机的任务资源，即应用程序的资源访问权限不受限制。

(6)非特权态

非特权态一般也可以称为用户态，是指应用程序运行时的状态，具有较低的特权级别。具体来说，如果一个应用程序运行在非特权态，该应用程序所访问的资源将会受到限制。

(7)内核

内核是操作系统最基本的部分，本质上是为众多应用程序提供对计算机硬件的安全访问的一部分软件。内核能够提供操作系统的最基本的功能，是操作系统工作的基础。

(8)进程间通信(Inter Process Communication，IPC)

IPC是指在不同进程之间传播或交换信息。

(9)进程(Process)

进程是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。

(10)线程(thread)

线程是操作系统能够进行运算调度的最小单位。线程被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

(11)系统调用

系统调用是操作系统提供给应用程序以请求内核服务的一种机制。系统调用本质上是操作系统提供给应用程序的编程接口，允许应用程序与操作系统的内核进行交互，以访问操作系统提供的服务和资源。系统调用是操作系统内核的一部分，通过系统调用，应用程序可以执行一些特权操作，例如文件访问，进程管理和网络通信。

经申请人研究发现，相较于单一内核架构，微内核架构在应用程序调用系统服务时往往会有更多的性能开销，导致应用程序调用系统服务的效率较低。

示例性地，请参阅图1，图1为相关技术的一种单一内核架构和微内核架构下应用程序调用系统服务的对比示意图。如图1所示，在单一内核架构下，在应用程序的运行过程中，应用程序对应的线程通过系统调用(system call，syscall)或exception进到内核后，由于所有内核组件位于同一个系统空间同一个特权态，所以内核可以通过函数调用的方式来获取各种系统服务。而在微内核系统中，应用程序对应的线程通过syscall或exception进到内核后，由于内核和系统服务的隔离性，需要再通过IPC来获取系统服务。并且，系统服务执行完成后，也需要通过IPC返回给线程。因此，与单一内核架构相比，线程调用一次系统服务多了最少两次IPC，导致对于每一个相同的操作系统功能，微内核架构都需要比单一内核架构做更多的工作。

相较于函数调用，IPC往往有着更繁重的开销。在微内核架构下，IPC主要包含连接建立和上下文切换等必要流程。其中，连接建立包括以下的多个步骤：a)鉴权，判断用户是否有权调用；b)查找或创建系统服务的执行实体；c)调用链的记录，内核需要记录整个调用过程，否则无法返回；d)将一些连接信息同步到系统服务。上下文切换至少包括以下的两个步骤：e)通用寄存器切换，以arm64架构为例，一次IPC要保存恢复31个通用寄存器；f)特权级和地址空间切换。

总的来说，由于微内核架构下大部分的系统服务与内核是隔离的，因此应用程序的线程在通过内核调用系统服务时往往需要执行IPC相关的多个步骤，导致应用程序的线程调用系统服务的效率较低。

有鉴于此，本申请提供一种系统服务的调用方法，在内核获取到线程首次调用某个系统服务的请求时，内核与该系统服务的执行实体建立连接并调用执行实体来处理请求，在执行实体完成请求的处理后，内核并不清理与执行实体之间的连接而是将执行实体的状态更新为托管状态，从而保留线程与该执行实体之间的对应关系。这样，在线程下次继续调用该系统服务时，内核则可以基于保留的对应关系以及与执行实体之间的连接，快速地调用处于托管状态的执行实体来处理线程的请求，从而提高线程调用系统服务的效率。并且，本申请提供的方法是应用于微内核架构下，能够保持微内核架构的优势，具备通用性以及良好的兼容性。

请参阅图2，图2为本申请提供的一种系统架构的示意图。如图2所示，在系统架构中，执行设备101例如可以为物理主机或物理服务器等设备。并且，执行设备101与数据存储系统102通信连接，用于获取数据存储系统102中所存储的程序代码，以实现本申请提供的系统服务的调用方法。其中，数据存储系统102例如可以是由部署于执行设备101上的存储设备实现，例如执行设备101为物理服务器，数据存储系统102为物理服务器上所部署的硬盘。数据存储系统102也可以是由独立于执行设备之外的存储设备实现，例如执行设备101为计算服务器，数据存储系统102则为专门存储程序代码的数据服务器。

执行设备101在工作期间，可以从数据存储系统102中获得程序代码以及执行系统服务的调用方法所需的相关数据，并且基于本申请提供的系统服务的调用方法在执行设备101上提供线程调用系统服务的效率。

请参阅图3，图3为本申请提供的一种执行设备101的结构示意图。如图3所示，本申请所提供的系统服务的调用方法所应用的执行设备101包括处理器103，处理器103和系统总线105耦合。处理器103可以是一个或者多个处理器，其中每个处理器都可以包括一个或多个处理器核。显示适配器(video adapter)107，显示适配器可以驱动显示器109，显示器109和系统总线105耦合。系统总线105通过总线桥111和输入输出(I/O)总线耦合。I/O接口115和I/O总线耦合。I/O接口115和多种I/O设备进行通信，比如输入设备117(如：触摸屏等)，外存储器121,(例如，硬盘、软盘、光盘或优盘)，多媒体接口等)。收发器123(可以发送和/或接收无线电通信信号)，摄像头155(可以捕捉静态和动态数字视频图像)和外部USB端口125。其中，可选地，和I/O接口115相连接的接口可以是USB接口。

其中，处理器103可以是任何传统处理器，包括精简指令集计算(reducedinstruction set Computing，RISC)处理器、复杂指令集计算(complex instruction setcomputing，CISC)处理器或上述的组合。可选地，处理器可以是诸如ASIC的专用装置。

执行设备101可以通过网络接口129和软件部署服务器149通信。示例性的，网络接口129是硬件网络接口，比如，网卡。网络127可以是外部网络，比如因特网，也可以是内部网络，比如以太网或者虚拟私人网络(virtual private network，VPN)。可选地，网络127还可以是无线网络，比如WiFi网络，蜂窝网络等。

硬盘驱动器接口131和系统总线105耦合。硬件驱动接口和硬盘驱动器133相连接。内存储器135和系统总线105耦合。运行在内存储器135的数据可以包括执行设备101的操作系统(OS)137、应用程序143和调度表。

操作系统包括Shell 139和内核(kernel)141。Shell 139是介于使用者和操作系统的内核间的一个接口。shell是操作系统最外面的一层。shell管理使用者与操作系统之间的交互：等待使用者的输入，向操作系统解释使用者的输入，并且处理各种各样的操作系统的输出结果。

内核141由操作系统中用于管理存储器、文件、外设和系统资源的那些部分组成。内核141直接与硬件交互，操作系统内核通常运行进程，并提供进程间的通信，提供CPU时间片管理、中断、内存管理和IO管理等等。

请参阅图4，图4为本申请提供的一种系统服务的调用方法的流程示意图。如图4所示，该系统服务的调用方法应用于微内核架构下的内核，具体包括以下的步骤401-403。

步骤401，在获取到来自于第一线程的第一调用请求时，通过与第一系统服务的执行实体建立连接来调用执行实体处理第一调用请求，其中第一调用请求用于请求调用第一系统服务。

在本申请中，第一线程具体可以为执行设备中所运行的用户的应用程序对应的一个线程，本申请对第一线程的具体形式并不做限定。在第一线程的运行过程中，当第一线程需要调用系统服务时，第一线程可以通过syscall或exception的方式向内核发送第一调用请求，该第一调用请求用于请求调用第一系统服务。

在内核获取到第一调用请求后，内核则查找资源池中是否具有已创建且空闲的第一系统服务的执行实体，如果资源池中存在已创建且空闲的第一系统服务的执行实体，内核则与该执行实体建立连接，并且调用执行实体处理第一调用请求。如果资源池中不存在已创建且空闲的第一系统服务的执行实体，内核则先创建一个第一系统服务的执行实体，再与该执行实体建立连接并调用执行实体处理第一调用请求。其中，资源池可以是用于存放已创建且未被其他线程所调用的执行实体。对于任意一个系统服务而言，内核可以是预先为该系统服务创建一个或多个执行实体，并将所创建的执行实体存放于资源池中，以便于后续在调用系统服务时能够从资源池中调用已创建的执行实体来处理相应的调用请求。

可选的，第一系统服务的执行实体与内核之间的连接例如为IPC连接。

具体而言，内核可以是通过IPC的方式来与第一系统服务的执行实体建立连接并调用执行实体处理第一调用请求。内核通过IPC的方式与执行实体建立连接并调用执行实体的过程可以参考上文的介绍，在此不再赘述。

此外，在内核调用第一系统服务的执行实体来处理来自于第一线程的第一调用请求时，内核需要记录第一线程与该执行实体之间的对应关系，以便于在获取到执行实体所返回的处理结果时能够将处理结果准确地返回给第一线程。

可选的，在本申请中，第一系统服务例如用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务等功能。总的来说，第一系统服务可以是用于提供除基础功能以外任意功能的系统服务，本申请对此并不做具体限定。

步骤402，在执行实体返回处理结果时，将处理结果返回给第一线程且将执行实体的状态更新为托管状态，其中处于托管状态下的执行实体与内核之间的连接不会被清理，且执行实体与第一线程具有对应关系。

在第一系统的执行实体对第一调用请求进行处理后，执行实体可以向内核返回处理结果。内核在获取到执行实体所返回的实体结果后，内核则将处理结果继续返回给第一线程，以实现第一线程调用第一系统服务的整个过程。

值得注意的是，在本申请中，内核将处理结果返回给第一线程后并不会清理内核与执行实体之间的连接，也不会释放执行实体至资源池中，而是将执行实体的状态更新为托管状态。处于托管状态下的执行实体与内核之间的连接不会被清理，而是会一直保持。在执行实体处于托管状态的情况下，内核将会托管执行实体且维持与执行实体之间的连接，从而使得执行实体只能够被第一线程所调用，而不能够再被其他的线程调用。

此外，内核在调用执行实体处理第一调用请求时所记录的第一线程与执行实体之间的对应关系也会保留，以指示当前处于托管状态的执行实体所对应的线程为第一线程。

步骤403，在获取到来自于第一线程的第二调用请求时，基于对应关系和连接调用执行实体来处理第二调用请求，第二调用请求用于请求调用第一系统服务。

本申请中，第一线程在需要继续调用第一系统服务的情况下，会向内核发送第二调用请求，以请求调用第一系统服务。在内核将第一系统服务的执行实体的状态更新为托管状态的情况下，内核获取到第二调用请求之后，内核可以基于所保留的第一线程与执行实体之间的对应关系，确定第一线程当前对应有处于托管状态的第一系统服务的执行实体。这样，内核则不需要再查找第一系统服务的其他执行实体来处理第二调用请求，而是基于内核与处于托管状态的执行实体之间的连接直接调用执行实体来处理第二调用请求，从而使得内核以接近直接调用的方式调用执行实体，而非以IPC的方式调用执行实体。

也就是说，在内核将某一个系统服务的执行实体更新为托管状态之后，如果与执行实体对应的线程继续调用相同的系统服务，内核则可以直接调用处于托管状态的执行实体来处理线程的调用请求，而无需基于常规的IPC方式与执行实体建立连接，从而省略执行实体调用过程中的多个步骤，提高系统服务的调用效率。

可选的，在上述的步骤402中，在将处理结果返回给第一线程后，内核还可以将第一线程的状态更新为对应有托管实体状态，其中对应有托管实体状态用于指示第一线程具有对应的被托管的执行实体。也就是说，第一线程与第一线程对应的执行实体的状态均发生了更新，第一线程的状态为对应有托管实体状态，而第一线程对应的执行实体的状态则为托管状态。

这样，在获取到来自于第一线程的第二调用请求时，基于第一线程的状态(即对应有托管实体状态)，内核可以是快速地确定当前需要调用处于托管状态的执行实体来处理第二调用请求，而不需要查找或创建其他的执行实体来处理第二调用请求。

也就是说，通过将第一线程的状态更新为对应有托管实体状态，可以使得内核在获取到来自于第一线程的调用请求时，快速地判断第一线程当前是否具有托管中的执行实体，进而确定后续是直接调用托管的执行实体还是查找或创建其他的执行实体，从而提高系统服务的调用效率。

可选的，上述的第一系统服务可以是处于特权态或非特权态。需要说明的是，在当前的处理器指令集架构中，在非特权态和特权态之间的切换往往伴随着处理器流水线清空等动作，进而带来额外的开销。具体来说，非特权态和特权态之间的切换会具有地址空间切换开销。由于在当前的处理器指令集架构中，一个处理器同时只能运行一个特权态地址空间以及一个非特权态地址空间，因此如果某一个系统服务处于非特权态，那么内核在调用该系统服务时，处理器则需要将调用该系统服务的线程的地址空间替换为系统服务的地址空间继续执行。此外，如果某一个系统服务是处于特权态，那么内核在调用该系统服务时，处理器并不需要替换地址空间，从而进一步了节省了特权级和地址空间切换的开销(即上文所介绍的开销f)。

其中，由于每个处理器都对应有一个寄存器来记录当前所运行的线程属于哪个地址空间，因此处理器所对应的寄存器指向的地址空间就称为处理器当前运行的地址空间。即，处理器所运行的特权态地址空间或非特权态地址空间是指处理器当前所运行的线程或执行实体所运行的地址空间。

以上介绍了在第一线程对应的执行实体处于托管状态下，当第一线程二次调用同一系统服务时内核直接调用该执行实体来处理第一线程所发送的调用请求。在一些情况下，第一线程所对应的执行实体可能并不能够用于处理第一线程后续所发送的调用请求，此时则可以是清理内核与该执行实体之间的连接且释放执行实体至资源池，以将执行实体从进对应于第一线程的托管状态变化至休眠等待状态。

在一个可能的示例中，在内核将第一系统服务的执行实体的状态更新为托管状态之后，在获取到来自于第一线程的用于请求调用第二系统服务的第三调用请求时，内核清理与上述执行实体之间的连接并将执行实体的状态更新为休眠等待状态。其中，处于休眠等待状态下的执行实体能够被其他的线程调用。即，内核实际上是清理与执行实体之间的IPC连接，并且将执行实体释放至资源池中，以使得执行实体的状态从仅对应于第一线程的托管状态变化为休眠等待状态。

然后，内核通过与第二系统服务的执行实体建立连接来调用第二系统服务的执行实体处理第三调用请求，并记录第一线程与第二系统服务的执行实体之间的对应关系。即，针对于调用第二系统服务的第三调用请求，由于第一线程当前并没有对应有处于托管状态的且属于第二系统服务的执行实体，因此内核需要查找或创建一个第二系统服务的执行实体来处理第三调用请求。

其中，内核通过与第二系统服务的执行实体建立连接来调用第二系统服务的执行实体处理第三调用请求与上述步骤401中内核与第一系统服务的执行实体建立连接且调用处理第一调用请求的过程类似，具体可以参考上述的步骤401，在此不再赘述。

类似地，当第二系统服务的执行实体处理完毕第三调用请求且向内核返回处理结果之后，内核将处理结果返回给第一线程并且保留第一线程与该第二系统服务的执行实体之间的对应关系，以及将第二系统服务的执行实体的状态更新为托管状态。这样一来，如果第一线程下次继续请求调用第二系统服务时，内核同样可以快速地调用第一线程所对应的第二系统服务的执行实体来处理来自于第一线程的请求。

本方案中，在线程对应有某一系统服务的且处于托管状态的执行实体的情况下，当线程请求调用另一个系统服务时，内核则触发清理与处于托管状态的执行实体之间的连接且将该执行实体释放，并且基于新的调用请求来与另一个系统服务的执行实体建立连接以调用另一个系统服务的执行实体来处理线程的调用请求，保证系统服务的正常调用，且避免同一个线程对应有过多的处于托管状态的执行实体而造成资源浪费。

在另一个可能的示例中，在内核将第一系统服务的执行实体的状态更新为托管状态之后，在获取到来自于第一线程的用于请求调用第一系统服务的第四调用请求时，如果该执行实体不可用，内核则清理与该执行实体之间的连接并将执行实体的状态更新为休眠等待状态。即，在第一线程继续调用同一系统服务的情况下，如果第一线程所对应的托管的执行实体本身不可用，那么内核也会清理与当前处于托管状态的执行实体之间的连接并释放该执行实体。

然后，内核通过与第一系统服务的其他执行实体建立连接来调用其他执行实体处理第四调用请求，并记录第一线程与其他执行实体之间的对应关系。

也就是说，如果如果处于托管状态的某一系统服务的执行实体不可用时，内核可以释放这个处于托管状态的执行实体，并且与同一系统服务下的其他执行实体建立连接并调用其他执行实体来处理线程的调用请求，以便于保证线程所发送的调用请求能够被正常处理，确保系统服务的正常调用。

其中，第一系统服务的执行实体不可用的原因具体可以为：当前处理器被第一系统服务的另一个执行实体所抢占，从而导致第一系统服务的其他所有执行实体此时均不能够在当前处理器上继续执行。当然，第一系统服务的执行实体不可用也可以是具有其他的原因，例如执行实体异常等原因，本申请对此并不做具体限定。

在第一系统服务的执行实体不可用的情况下，由于通知该执行实体不可在当前处理器上继续执行的流程开销与重新调用新的执行实体的流程开销接近，因此本方案中是释放托管状态下的执行实体并且基于调用请求重新调用新的执行实体来处理，从而尽可能减少对现有技术的改动，且不会引入额外的开销，提高本方案的可实现性和兼容性。

可选的，在本申请中，第一线程在同一时间仅对应于一个被托管的执行实体。也就是说，在同一时间下，内核只会为第一线程托管一个执行实体，而不会为第一线程托管多个不同的执行实体。一般来说，在内核为线程托管一个执行实体的情况下，就能够有效地提高系统服务的调用效率；在内核为线程托管多个执行实体的情况下，相较于内核仅仅为线程托管一个执行实体，并没有为系统服务的调用效率带来进一步的明显提高。但是，相较于内核仅仅为线程托管一个执行实体，内核为线程托管多个执行实体具有相当高的复杂度，且需要占据较多的处理资源，因此通过设定内核在同一时间下仅为同一个线程托管一个执行实体，能够保证在具有较高的系统服务调用效率的同时，尽可能地降低系统复杂度以及系统所占据的处理资源。

当然，在一些实施例中，内核也可以是为第一线程托管多个执行实体，且多个执行实体为不同系统服务下的执行实体。这样，在第一线程重复调用已调用过的系统服务时，内核都能够直接调用处于托管状态下的执行实体，从而提高在各种情况下的系统服务调用效率。

以上介绍了本申请提供的系统服务的调用方法，为便于理解，以下将结合具体例子详细介绍本申请提供的系统服务的调用方法的执行过程。

请参阅图5，图5为本申请提供的一种系统服务的调用方法的应用场景示意图。如图5所示，本申请提供的系统服务的调用方法应用于微内核架构，该微内核架构包括以下三个层级的组件：内核、系统服务和用户进程。在微内核架构中，用户层面的不同应用程序在运行时表现为不同的用户进程(例如图5中的用户进程1-用户进程)，且每个用户进程中可以运行有一个或多个线程。微内核架构下可以包括多个系统服务，不同的系统服务可以用于提供不同的系统功能，例如图5中所示的内存管理、文件系统、进程管理、设备驱动以及网络协议等功能。并且，同一个系统服务可以是具有一个或多个执行实体，由执行实体来负责实现提供系统服务对应的功能。

具体地，线程使用操作系统的所有功能的入口，都是触发系统调用(syscall)或者异常处理(exception)。线程首先进入到内核后，内核再根据线程所请求的功能，决定自行处理，或者派发到相应的系统服务来完成。同样的，系统服务处理完成后，也是触发一个专用的系统调用进入到内核，内核中跟踪了线程与系统服务之间的调用关系，因此此时内核能够将处理结果返回给线程，使得线程继续执行。

请参阅图6，图6为本申请提供的一种微内核架构下线程调用系统服务的对比示意图。如图6所示，在相关技术中，线程通过syscall或exception进到内核后，内核需要通过IPC来获取系统服务。并且，系统服务执行完成后，先通过syscall或exception的方式将处理结果返回给内核，再由内核通过IPC的方式将处理结果返回给线程。

在本申请提供的方案中，线程向内核发起一次请求来获取系统服务，内核仍然使用IPC方式为线程提供系统服务。在系统服务完成请求的处理后，从系统服务进入到内核，再回到线程之前，内核并不会释放执行实体以及清理IPC连接，而是将当前使用的系统服务的执行实体进行托管。

这样一来，线程再次调用系统服务时，可以先通过syscall或exception的方式进入到内核；此时内核可以直接调用被托管的执行实体来处理线程所发送的调用请求，而不需要再基于IPC的方式来获取系统服务，进而免却IPC相关的多个步骤。

本方案是在微内核架构上的动态优化，而非整个系统的架构重构，所以能够保持微内核架构的优势，具有良好的兼容性。并且，在本方案中，所有的动作都是在内核和系统服务中完成，对用户侧的线程透明(即无需调整用户侧的应用程序的代码)，同时也没有对可移植操作系统接口规范(portable operating systeminterface，POSIX)语义冲突的修改，因此具有良好的通用性和可实施性。

请参阅图7，图7为本申请提供的一种线程调用系统服务的流程示意图。如图7所示，在微内核架构下，线程调用系统服务的流程包括以下的步骤701-706。

步骤701，线程首次发起对系统服务的调用。

示例性地，请参阅图8，图8为本申请提供的一种线程在不同情况下调用系统服务的流程示意图。如图8所示，在线程首次发起对系统服务的调用时，线程可以是先通过syscall的方式向内核发送调用请求，以请求调用系统服务。

在接收到线程所发送的调用请求后，内核通过IPC的方式来调用系统服务的执行实体来处理线程所发送的调用请求。具体地，内核会基于线程所发送的调用请求，在资源池中查找或创建系统服务的执行实体，并且记录调用信息，然后再跳转到系统服务的执行实体来处理线程所发送的调用请求。

由于来自于线程的调用请求每次都需要系统服务的一个执行实体来处理，且系统服务的执行实体一般表现为一个用户栈以及服务调用的相关信息(例如调用者的信息或者本次调用的参数或结果)，因此内核每接收到来自于线程的调用请求后，都可以是查找一个用于处理调用请求的执行实体，或者是在无法在资源池中查找到用于处理调用请求的执行实体时新创建一个执行实体。其中，用户栈是指位于系统服务进程空间中的一片区域。

在内核调用执行实体来处理调用请求时，内核还会记录调用请求所对应的调用信息。具体来说，在线程所发送的调用请求能够由一个系统服务来完成的情况下，内核则记录线程与所调用的系统服务的执行实体之间的调用关系。在线程所发送的调用请求需要多个系统服务来配合完成的情况下，多个系统服务的执行实体之间还具有进一步的调用关系，因此内核则是记录线程与系统服务的执行实体，以及各个系统服务的执行实体之间的调用关系。例如，假设线程请求读取一个文件，首先要调用到文件系统服务，文件系统再通过调用驱动系统服务来获取存储于磁盘中的数据，即调用链为线程→文件系统服务→驱动系统服务。此时，内核则可以是采用一个数据结构(例如stack)来记录调用链，以实现调用信息的记录。

步骤702，系统服务首次调用完成后，将系统服务的执行实体托管于内核中。

如图8所示，在系统服务的执行实体完成对调用请求的处理后，系统服务的执行实体通过syscall的方式向内核返回处理结果。此时，内核可以是将该系统服务的执行实体标记为托管状态，即实现将该系统服务的执行实体托管在内核，并且内核通过IPC的方式向线程返回处理结果。

具体地，在本方案中，分别为线程状态机和系统服务的执行实体的状态机中新引入一个中间状态，用于标记系统服务的执行实体处于托管状态。一般来说，微内核架构下的内核通常是通过状态机来跟踪线程以及各个执行实体的状态，状态机的转换一般与调用链的变更同步进行。

示例性地，请参阅图9，图9为本申请提供的一种线程状态机和系统服务的执行实体的状态机的示意图。如图9所示，为了实现在内核托管系统服务的执行实体，分别为线程新引入对应有托管实体状态(part-inacvt)，为系统服务的执行实体新引入托管状态(part-actv)，且对应有托管实体状态和托管状态是成对出现的。当线程的状态为对应有托管实体状态时，线程对应的系统服务的执行实体则为托管状态。

在图9中，线程状态机中包括三个状态，分别为活跃状态(active)、对应有托管实体状态和休眠等待状态(inactive)。在线程未调用系统服务时，线程处于休眠等待状态；在线程向内核发送调用请求，触发调用系统服务时，线程从休眠等待状态变化为活跃状态；在内核为线程托管对应的系统服务的执行实体时，线程则从活跃状态变化为对应有托管实体状态；在内核清除为线程所托管的系统服务的执行实体时，线程则从对应有托管实体状态变化为休眠等待状态。

类似地，系统服务的执行实体状态机中业包括三个状态，分别为活跃状态、托管状态和休眠等待状态(inactive)。在系统服务的执行实体未被调用时，系统服务的执行实体处于休眠等待状态；在内核调用系统服务的执行实体来处理来自于线程的调用请求时，系统服务的执行实体从休眠等待状态变化为活跃状态；在内核为线程托管对应的系统服务的执行实体时，系统服务的执行实体则从活跃状态变化为托管状态；在内核清除为线程所托管的系统服务的执行实体时，系统服务的执行实体则从托管状态变化为休眠等待状态。

需要说明的是，通过在状态机引入新的状态，可以使得内核在接收到来自于线程的调用请求时，快速地判断如何处理调用请求。例如，在接收到来自于线程的调用请求时，内核可以查看线程状态机，如果当前线程的状态为休眠等待状态，代表本次调用是线程首次发起的系统服务调用，因此内核需要查找或创建对应的系统服务的执行实体来处理调用请求；如果当前线程的状态为对应有托管实体状态，则代表已经为线程托管有对应的执行实体，因此内核需要进一步判断为线程所托管的执行实体是否可用。

在内核托管系统服务的执行实体时，内核并不会释放该系统服务的执行实体，也不会清理内核与该系统服务的执行实体之间的连接，从而保留内核所记录的线程与该系统服务的执行实体之间的对应关系。

其中，对于操作系统中所运行的任意一个线程，内核在为线程调用相应的系统服务的执行实体之后，都可以为线程托管一个对应的执行实体，从而建立起线程与执行实体之间的托管关系。示例性地，请参阅图10，图10为本申请提供的一种线程、内核与执行实体之间的关系示意图。如图10所示，内核可以为每个线程都唯一地托管一个对应的系统服务的执行实体，从而使得不同的线程在调用系统服务后都能够对应有一个托管的执行实体。

步骤703，线程继续发起对系统服务的调用。

在线程获取到内核所返回的处理结果后，线程可以根据实际运行需要继续发起对系统服务的调用。其中，线程可以是继续发起对同一系统服务的调用，也可以是发起对不同系统服务的调用。即，线程所调用的系统服务与上一次所调用的系统服务可以是相同的，也可以是不相同的。

步骤704，内核判断为线程托管的执行实体是否可用。

由于在步骤702中，内核已经为线程托管有对应的执行实体，因此内核可以进一步基于所保留的调用信息来判断当前为线程托管的执行实体是否可用，以便于确定能否优先采用托管的执行实体来处理线程再次发送的调用请求。

其中，为线程托管的执行实体不可用的原因可以有两类。

第一类原因为主动原因：线程本次所调用的系统服务与为线程托管的执行实体所对应的系统服务并不相同。例如，线程上一次调用的是文件系统服务，因此内核为线程托管了文件系统服务的执行实体；但是，线程本次所调用的是驱动系统服务，内核为线程所托管的执行实体是文件系统服务下的执行实体，因此内核所托管的文件系统服务的执行实体不可用。

第二类原因为被动原因：为线程托管的执行实体的状态变更。例如，为线程托管的执行实体本身异常；或者是当前处理器上已运行有一个相同系统服务的执行实体，导致为托管的执行实体无法继续在当前处理器上运行。

步骤705，如果托管的执行实体可用，内核使用托管的执行实体来提供服务。

如图8所示，如果托管的执行实体可用，此时内核可以快速地调用托管的执行实体(类似于函数调用的方式)来处理来自于线程的调用请求，而无需再重新通过IPC的方式来调用执行实体处理调用请求。

需要说明的是，当内核为线程托管的系统服务的执行实体是运行在特权态时，在调用系统服务的执行实体来处理调用请求时，无需在处理器上将线程所在的进程对应的地址空间替换为系统服务对应的地址空间来执行，从而进一步省去地址空间的替换开销。

步骤706，如果托管的执行实体不可用，内核清理托管的执行实体，并通过IPC来调用新的执行实体来提供服务。

如图8所示，如果托管的执行实体不可用，内核需要清理托管的执行实体(即清理内核与托管的执行实体之间的连接关系并且将该执行实体释放至资源池中)。并且，内核还需要通过IPC来调用新的执行实体来处理来自于线程的调用请求。

需要说明的是，在内核调用IPC调用新的执行实体完成来自于线程的调用请求后，内核会为线程继续托管新的执行实体，从而尽可能保证线程在每次调用完系统服务之后都能够对应有一个托管的执行实体。

以上详细介绍了本申请提供的方法，接下来将介绍本申请提供的用于执行上述方法的设备。

请参阅图11，图11为本申请提供的一种系统服务的调用装置的结构示意图。如图11所示，该系统服务的调用装置，应用于实现微内核架构下的内核，该系统服务的调用装置包括：收发模块1101和处理模块1102；

在收发模块1101获取到来自于第一线程的第一调用请求时，处理模块1102用于通过与第一系统服务的执行实体建立连接来调用执行实体处理第一调用请求，其中第一调用请求用于请求调用第一系统服务；

在执行实体返回处理结果时，收发模块1101用于将处理结果返回给第一线程且处理模块1102还用于将执行实体的状态更新为托管状态，其中处于托管状态下的执行实体与内核之间的连接不会被清理，且执行实体与第一线程具有对应关系；

在收发模块1101获取到来自于第一线程的第二调用请求时，处理模块1102还用于基于对应关系和连接调用执行实体来处理第二调用请求，第二调用请求用于请求调用第一系统服务。

在一种可能的实现方式中，在收发模块1101将处理结果返回给第一线程后，处理模块1102还用于将第一线程的状态更新为对应有托管实体状态，对应有托管实体状态用于指示第一线程具有对应的被托管的执行实体；

在收发模块1101获取到来自于第一线程的第二调用请求时，处理模块1102还用于基于第一线程的状态，确定调用处于托管状态的执行实体来处理第二调用请求。

在一种可能的实现方式中，在收发模块1101获取到来自于第一线程的第三调用请求时，处理模块1102还用于清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第三调用请求用于请求调用第二系统服务，处于休眠等待状态下的执行实体能够被其他的线程调用；

处理模块1102还用于通过与第二系统服务的执行实体建立连接来调用第二系统服务的执行实体处理第三调用请求，并记录第一线程与第二系统服务的执行实体之间的对应关系。

在一种可能的实现方式中，在收发模块1101获取到来自于第一线程的第四调用请求时，若执行实体不可用，处理模块1102还用于清理与执行实体之间的连接并将执行实体的状态更新为休眠等待状态，其中第四调用请求用于请求调用第一系统服务；

处理模块1102还用于通过与第一系统服务的其他执行实体建立连接来调用其他执行实体处理第四调用请求，并记录第一线程与其他执行实体之间的对应关系。

在一种可能的实现方式中，第一线程在同一时间对应于一个被托管的执行实体。

在一种可能的实现方式中，第一系统服务处于特权态或非特权态。

在一种可能的实现方式中，执行实体与内核之间的连接为IPC连接。

在一种可能的实现方式中，第一系统服务用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务。

请参阅图12，图12为本申请提供的一种电子设备的结构示意图。如图12所示，电子设备1200具体可以表现为服务器，此处不做限定。具体的，电子设备1200包括：接收器1201、发送器1202、处理器1203和存储器1204(其中电子设备1200中的处理器1203的数量可以一个或多个，图12中以一个处理器为例)，其中，处理器1203可以包括应用处理器12031和通信处理器12032。在本申请的一些实施例中，接收器1201、发送器1202、处理器1203和存储器1204可通过总线或其它方式连接。

存储器1204可以包括只读存储器和随机存取存储器，并向处理器1203提供指令和数据。存储器1204的一部分还可以包括非易失性随机存取存储器(non-volatile randomaccess memory，NVRAM)。存储器1204存储有处理器和操作指令、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，操作指令可包括各种操作指令，用于实现各种操作。

处理器1203控制电子设备的操作。具体的应用中，电子设备的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都称为总线系统。

上述本申请实施例揭示的方法可以应用于处理器1203中，或者由处理器1203实现。处理器1203可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1203中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1203可以是通用处理器、数字信号处理器(digital signal processing，DSP)、微处理器或微控制器，还可进一步包括专用集成电路(application specific integratedcircuit，ASIC)、现场可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

该处理器1203可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1204，处理器1203读取存储器1204中的信息，结合其硬件完成上述方法的步骤。

接收器1201可用于接收输入的数字或字符信息，以及产生与电子设备的相关设置以及功能控制有关的信号输入。发送器1202可用于通过第一接口输出数字或字符信息；发送器1202还可用于通过第一接口向磁盘组发送指令，以修改磁盘组中的数据；发送器1202还可以包括显示屏等显示设备。

本申请实施例提供的电子设备具体可以为芯片，芯片包括：处理单元和通信单元，处理单元例如可以是处理器，通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使执行设备内的芯片执行上述实施例描述的方法。可选地，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是无线接入设备端内的位于芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。

可以参阅图13，图13为本申请提供的一种计算机可读存储介质的结构示意图。本申请还提供了一种计算机可读存储介质，在一些实施例中，上述图4所公开的方法可以实施为以机器可读格式被编码在计算机可读存储介质上或者被编码在其它非瞬时性介质或者制品上的计算机程序指令。

图13示意性地示出根据这里展示的至少一些实施例而布置的示例计算机可读存储介质的概念性局部视图，示例计算机可读存储介质包括用于在计算设备上执行计算机进程的计算机程序。

在一个实施例中，计算机可读存储介质1300是使用信号承载介质1301来提供的。信号承载介质1301可以包括一个或多个程序指令1302，其当被一个或多个处理器运行时可以提供以上针对图4描述的功能或者部分功能。

在一些示例中，信号承载介质1301可以包含计算机可读介质1303，诸如但不限于，硬盘驱动器、紧密盘(CD)、数字视频光盘(DVD)、数字磁带、存储器、ROM或RAM等等。

在一些实施方式中，信号承载介质1301可以包含计算机可记录介质1304，诸如但不限于，存储器、读/写(R/W)CD、R/W DVD、等等。在一些实施方式中，信号承载介质1301可以包含通信介质1305，诸如但不限于，数字和/或模拟通信介质(例如，光纤电缆、波导、有线通信链路、无线通信链路、等等)。因此，例如，信号承载介质1301可以由无线形式的通信介质1305(例如，遵守IEEE 802.X标准或者其它传输协议的无线通信介质)来传达。

一个或多个程序指令1302可以是，例如，计算机可执行指令或者逻辑实施指令。在一些示例中，计算设备的计算设备可以被配置为，响应于通过计算机可读介质1303、计算机可记录介质1304、和/或通信介质1305中的一个或多个传达到计算设备的程序指令1302，提供各种操作、功能、或者动作。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid StateDisk，SSD))等。

Claims (19)

1.一种系统服务的调用方法，其特征在于，所述方法应用于微内核架构下的内核，所述方法包括：

在获取到来自于第一线程的第一调用请求时，通过与第一系统服务的执行实体建立连接来调用所述执行实体处理所述第一调用请求，其中所述第一调用请求用于请求调用所述第一系统服务；

在所述执行实体返回处理结果时，将所述处理结果返回给所述第一线程且将所述执行实体的状态更新为托管状态，其中处于托管状态下的所述执行实体与所述内核之间的连接不会被清理，且所述执行实体与所述第一线程具有对应关系；

在获取到来自于所述第一线程的第二调用请求时，基于所述对应关系和所述连接调用所述执行实体来处理所述第二调用请求，所述第二调用请求用于请求调用所述第一系统服务。

2.根据权利要求1所述的方法，其特征在于，在将所述处理结果返回给所述第一线程后，所述方法还包括：

将所述第一线程的状态更新为对应有托管实体状态，所述对应有托管实体状态用于指示所述第一线程具有对应的被托管的执行实体；

在获取到来自于所述第一线程的第二调用请求时，基于所述第一线程的状态，确定调用处于托管状态的所述执行实体来处理所述第二调用请求。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在获取到来自于所述第一线程的第三调用请求时，清理与所述执行实体之间的连接并将所述执行实体的状态更新为休眠等待状态，其中所述第三调用请求用于请求调用第二系统服务，处于休眠等待状态下的所述执行实体能够被其他的线程调用；

通过与所述第二系统服务的执行实体建立连接来调用所述第二系统服务的执行实体处理所述第三调用请求，并记录所述第一线程与所述第二系统服务的执行实体之间的对应关系。

4.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在获取到来自于所述第一线程的第四调用请求时，若所述执行实体不可用，则清理与所述执行实体之间的连接并将所述执行实体的状态更新为休眠等待状态，其中所述第四调用请求用于请求调用所述第一系统服务；

通过与所述第一系统服务的其他执行实体建立连接来调用所述其他执行实体处理所述第四调用请求，并记录所述第一线程与所述其他执行实体之间的对应关系。

5.根据权利要求1-4任意一项所述的方法，其特征在于，所述第一线程在同一时间对应于一个被托管的执行实体。

6.根据权利要求1-5任意一项所述的方法，其特征在于，所述第一系统服务处于特权态或非特权态。

7.根据权利要求1-6任意一项所述的方法，其特征在于，所述执行实体与所述内核之间的连接为进程间通信IPC连接。

8.根据权利要求1-7任意一项所述的方法，其特征在于，所述第一系统服务用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务。

9.一种系统服务的调用装置，其特征在于，所述装置应用于实现微内核架构下的内核，所述装置包括：收发模块和处理模块；

在所述收发模块获取到来自于第一线程的第一调用请求时，所述处理模块用于通过与第一系统服务的执行实体建立连接来调用所述执行实体处理所述第一调用请求，其中所述第一调用请求用于请求调用所述第一系统服务；

在所述执行实体返回处理结果时，所述收发模块用于将所述处理结果返回给所述第一线程且所述处理模块还用于将所述执行实体的状态更新为托管状态，其中处于托管状态下的所述执行实体与所述内核之间的连接不会被清理，且所述执行实体与所述第一线程具有对应关系；

在所述收发模块获取到来自于所述第一线程的第二调用请求时，所述处理模块还用于基于所述对应关系和所述连接调用所述执行实体来处理所述第二调用请求，所述第二调用请求用于请求调用所述第一系统服务。

10.根据权利要求9所述的装置，其特征在于，在所述收发模块将所述处理结果返回给所述第一线程后，所述处理模块还用于将所述第一线程的状态更新为对应有托管实体状态，所述对应有托管实体状态用于指示所述第一线程具有对应的被托管的执行实体；

在所述收发模块获取到来自于所述第一线程的第二调用请求时，所述处理模块还用于基于所述第一线程的状态，确定调用处于托管状态的所述执行实体来处理所述第二调用请求。

11.根据权利要求9或10所述的装置，其特征在于，

在所述收发模块获取到来自于所述第一线程的第三调用请求时，所述处理模块还用于清理与所述执行实体之间的连接并将所述执行实体的状态更新为休眠等待状态，其中所述第三调用请求用于请求调用第二系统服务，处于休眠等待状态下的所述执行实体能够被其他的线程调用；

所述处理模块还用于通过与所述第二系统服务的执行实体建立连接来调用所述第二系统服务的执行实体处理所述第三调用请求，并记录所述第一线程与所述第二系统服务的执行实体之间的对应关系。

12.根据权利要求9或10所述的装置，其特征在于，

在所述收发模块获取到来自于所述第一线程的第四调用请求时，若所述执行实体不可用，所述处理模块还用于清理与所述执行实体之间的连接并将所述执行实体的状态更新为休眠等待状态，其中所述第四调用请求用于请求调用所述第一系统服务；

所述处理模块还用于通过与所述第一系统服务的其他执行实体建立连接来调用所述其他执行实体处理所述第四调用请求，并记录所述第一线程与所述其他执行实体之间的对应关系。

13.根据权利要求9-12任意一项所述的装置，其特征在于，所述第一线程在同一时间对应于一个被托管的执行实体。

14.根据权利要求9-13任意一项所述的装置，其特征在于，所述第一系统服务处于特权态或非特权态。

15.根据权利要求9-14任意一项所述的装置，其特征在于，所述执行实体与所述内核之间的连接为IPC连接。

16.根据权利要求9-15任意一项所述的装置，其特征在于，所述第一系统服务用于提供以下的任意一个或多个功能：进程管理、内存管理、文件系统、设备驱动以及网络服务。

17.一种系统服务的调用装置，其特征在于，包括存储器和处理器；所述存储器存储有代码，所述处理器被配置为执行所述代码，当所述代码被执行时，所述装置执行如权利要求1至8任一项所述的方法。

18.一种计算机存储介质，其特征在于，所述计算机存储介质存储有指令，所述指令在由计算机执行时使得所述计算机实施权利要求1至8任意一项所述的方法。

19.一种计算机程序产品，其特征在于，所述计算机程序产品存储有指令，所述指令在由计算机执行时使得所述计算机实施权利要求1至8任意一项所述的方法。