CN115495262A - 一种微内核操作系统及进程间消息的处理方法 - Google Patents

Abstract

本申请提供一种微内核操作系统及进程间消息的处理方法，微内核操作系统包括用户进程、微内核及服务进程，服务进程包括进程间通信守护线程和消息分发守护线程；进程间通信守护线程用于通过微内核接收用户进程发送且设置优先级的请求消息，并解析请求消息以确定操作行为类型，并将请求消息发送给与操作行为类型对应的消息分发守护线程使用的请求消息列表；消息分发守护线程用于按照请求消息列表中请求消息的优先级依次根据请求消息访问服务进程对应的设备。解决了现有技术中微内核操作系统的服务进程需要预先准备大量线程以便处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高的问题。

Description

一种微内核操作系统及进程间消息的处理方法

技术领域

本申请涉及汽车控制领域，尤其涉及一种微内核操作系统及进程间消息的处理方法。

背景技术

微内核操作系统(Microkernel Operating System)作为一种基于微内核架构的操作系统，仅在微内核中保留了进程间通信(Inter-Process Communication，简称IPC)、内存管理单元(Memory Management Unit，MMU)以及进程调度等功能，而将其他功能移至用户态以服务进程的方式来实现，保证了服务进程之间的强隔离，使得微内核操作系统具备高度的稳定性和可靠性。

现有技术的微内核操作系统，如QNX操作系统，在用户进程通过微内核将请求消息发送至服务进程时，用户进程发出的每条请求消息皆需要服务进程提供一条线程进行处理，直至返回处理结果。

也就是说，现有技术中，无论待处理的请求消息的个数为多少，微内核操作系统的服务进程皆需要预先准备大量线程以便处理请求消息，另外，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高的问题。

发明内容

本申请提供一种微内核操作系统及进程间消息的处理方法，用于解决现有技术中，微内核操作系统的服务进程需要预先准备大量线程以便处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高的问题。

第一方面，本申请提供一种微内核操作系统，包括用户进程、微内核以及服务进程，所述服务进程包括进程间通信守护线程和消息分发守护线程；其中，

所述进程间通信守护线程，用于通过所述微内核接收所述用户进程发送的请求消息；其中，所述请求消息为所述用户进程生成并设置优先级的请求消息；

所述进程间通信守护线程，还用于对所述请求消息进行解析处理，确定所述请求消息的操作行为类型，并将所述请求消息保存到与所述请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表；

所述消息分发守护线程，用于按照所述消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对所述服务进程对应的设备进行访问处理。

在上述微内核操作系统的优选技术方案中，

所述服务进程，用于根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程。

在上述微内核操作系统的优选技术方案中，当所述设备的类型为串行执行类型时，所述服务进程，具体用于：

调用一次所述第二注册接口，以创建一个消息分发守护线程；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

在上述微内核操作系统的优选技术方案中，当所述设备的类型为可并发执行类型时，所述服务进程，具体用于：

调用至少一次所述第二注册接口，以创建至少一个消息分发守护线程；其中，创建消息分发守护线程的个数可通过所述第二注册接口进行设定；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

在上述微内核操作系统的优选技术方案中，所述消息分发守护线程，还用于将访问所述设备的结果通过所述微内核反馈给所述用户进程。

第二方面，本申请提供一种微内核操作系统的进程间消息的处理方法，应用于服务进程，所述服务进程包括进程间通信守护线程和消息分发守护线程，所述方法包括：

所述进程间通信守护线程通过微内核接收用户进程发送的请求消息；其中，所述请求消息为所述用户进程生成并设置优先级的请求消息；

所述进程间通信守护线程对所述请求消息进行解析处理，确定所述请求消息的操作行为类型，并将所述请求消息保存到与所述请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表；

所述消息分发守护线程按照所述消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对所述服务进程对应的设备进行访问处理。

在上述微内核操作系统的进程间消息的处理方法的优选技术方案中，还包括：

所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程。

在上述微内核操作系统的进程间消息的处理方法的优选技术方案中，当所述设备的类型为串行执行类型时，所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程，具体包括：

调用一次所述第二注册接口，以创建一个消息分发守护线程；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

在上述微内核操作系统的进程间消息的处理方法的优选技术方案中，当所述设备的类型为可并发执行类型时，所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程，具体包括：

调用至少一次所述第二注册接口，以创建至少一个消息分发守护线程；其中，创建消息分发守护线程的个数可通过所述第二注册接口进行设定；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

在上述微内核操作系统的进程间消息的处理方法的优选技术方案中，还包括：

所述消息分发守护线程将访问所述设备的结果通过所述微内核反馈给所述用户进程。

本申请提供一种微内核操作系统及进程间消息的处理方法，该微内核操作系统包括用户进程、微内核以及服务进程，其中，服务进程包括两种类型的线程——进程间通信守护线程和消息分发守护线程。进程间通信守护线程用于通过微内核接收用户进程发送的由用户进程生成并设置优先级的请求消息。进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息分发给与请求消息的操作行为类型绑定的消息分发守护线程。在进程间通信守护线程对请求消息的分发中，进程间通信守护线程会将请求消息保存到与请求消息的操作行为类型对应的请求消息列表中，并唤醒绑定在与请求消息的操作行为类型对应的所有消息分发守护线程中的一个消息分发守护线程，该被唤醒的消息分发守护线程用于按照请求消息列表中请求消息的优先级从高到低的顺序，取出优先级最高的请求消息对服务进程对应的设备进行访问处理。相较于现有技术中，微内核操作系统的服务进程需要预先准备大量线程以便处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高而言，本申请仅需借助进程间通信守护线程和分发守护线程，即可实现对大量请求消息的处理，降低了微内核操作系统的开销。另外，本申请无需设置互斥锁，通过对请求消息的分操作行为类型、分优先级的处理，即可解决多线程并发访问设备的问题，降低了微内核操作系统的开发复杂度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例一提供的一种微内核操作系统的结构示意图；

图2为本申请实施例四提供的一种微内核操作系统的结构示意图；

图3为本申请实施例五提供的一种微内核操作系统的结构示意图；

图4为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例一的流程示意图；

图5为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例二的流程示意图；

图6为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例三的流程示意图；

图7为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例四的流程示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在根据本实施例的启示下作出的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在汽车控制领域，主要应用QNX操作系统，即目前QNX的进程间的远程调用(RemoteProcedure Call，简称RPC)仍然是车载内核实时操作系统(Real Time Operating System，简称RTOS)的主流方案。以驱动设备为例，举例来说，设备初始化时申请一个进程间通信线程池，APP客户端(App client)访问某个驱动设备驱动服务端(Driver server)，通过进程间通信将open/read/write/close等“请求”发送给Driver server，每条“请求”将唤醒Driver server提前注册的线程池其中的一条线程进行处理，该线程访问完设备后将成功或者失败结果通过进程间通信再返回给App client后继续等待下一条“请求”。由此，每条“请求”都会占用一条线程，大量的线程，造成系统开销大，且存在多线程并发访问设备的情况，需要通过加锁或者放入先进先出(First Input First Output，简称FIFO)等机制来解决这种并发问题。但是，加锁或者FIFO等机制的引用会提高驱动开发的复杂度，也容易引入死锁等非可靠性问题。

基于上述技术问题，本申请的技术构思过程如下：在微内核操作系统中，使用线程完成服务进程的工作时，如何在保证请求实时性返回的同时，还能有效地减少多线程带来的开销问题和设置互斥锁带来的开发复杂度等问题。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图1为本申请实施例一提供的一种微内核操作系统的结构示意图。参见图1，该微内核操作系统10包括：用户进程101、微内核102以及服务进程103。

在本实施例中，该微内核操作系统10可以是QNX操作系统，也可以是其他操作系统，本申请并不对此进行限制。

另外，服务进程103可以包括进程间通信守护线程104和消息分发守护线程105。需要说明的是，图1中仅示出了一个消息分发守护线程，而在实际应用中，消息分发守护线程的数量可视设备的类型而定，本申请实施例不做限定。

更为具体的，当用户进程101需要对服务进程103对应的设备进行访问时，用户进程101生成包括服务进程103的ID值(服务进程103的通道)的请求消息，并设置请求消息的优先级。举例来说，请求消息可以为读取请求或者写入请求。用户进程将已经设置优先级的请求消息通过可移植操作系统接口(Portable Operating System Interface，简称POSIX)发送至微内核102。

微内核102接收用户进程101发送的请求消息后，获取请求消息中的服务进程103的ID值，微内核102将请求消息发送至与上述ID值对应的服务进程103。

服务进程103中的进程间通信守护线程104在接收到微内核102发送的请求消息时被唤醒，并对请求消息进行解析，以确定请求消息的操作行为类型。其中，当请求消息为读取请求时，该请求消息的操作行为类型为读取类型，当请求消息为写入请求时，该请求消息的操作行为类型为写入类型。进程间通信守护线程104在确定请求消息的操作行为类型后，将该请求消息保存到与请求消息的操作行为类型绑定的所有消息分发守护线程所共用的一个请求消息列表中，同时唤醒其中一个消息分发守护线程，可以理解地，此处唤醒的消息分发守护线程可以为消息分发守护线程105。

消息分发守护线程105使用的请求消息列表中存储有待处理的请求消息。被唤醒的消息分发守护线程105按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息对服务进程103对应的设备进行访问。

需要说明的是，本申请实施例中的设备可以为硬件设备，也可以为虚拟设备，本申请实施例不对设备所属类别进行限定。

在本实施例中，微内核操作系统包括用户进程、微内核以及服务进程，其中，服务进程包括两种类型的线程——进程间通信守护线程和消息分发守护线程。进程间通信守护线程用于通过微内核接收用户进程发送的由用户进程生成并设置优先级的请求消息。进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息分发给与请求消息的操作行为类型绑定的消息分发守护线程。在进程间通信守护线程对请求消息的分发中，进程间通信守护线程会将请求消息保存到与请求消息的操作行为类型对应的请求消息列表中，并唤醒绑定在与请求消息的操作行为类型对应的所有消息分发守护线程中的一个消息分发守护线程，该被唤醒的消息分发守护线程用于按照请求消息列表中请求消息的优先级从高到低的顺序，取出优先级最高的请求消息对服务进程对应的设备进行访问处理。相较于现有技术中，微内核操作系统的服务进程需要预先准备大量线程以便处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高而言，本申请仅需借助进程间通信守护线程和分发守护线程，即可实现对请求消息的合并、调度及快速处理，降低了微内核操作系统的开销。另外，本申请无需设置互斥锁，通过对请求消息的分操作行为类型、分优先级的处理，即可解决多线程并发访问设备的问题，降低了微内核操作系统的开发复杂度。

下面通过实施例二对服务进程创建进程间通信守护线程和消息分发守护线程的过程进行详细说明。

需要说明的是，本实施例中服务进程创建消息分发守护线程的数量为至少一个。为了便于说明，本实施例仅以应用于上述图1所示的微内核操作系统的结构示意图为例。创建消息分发守护线程的数量应视具体情况而定。

当服务进程103调用第一注册接口时，可以创建进程间通信守护线程，可选地，服务进程103调用第一注册接口的次数可以为服务进程103创建进程间通信守护线程的条数。

当服务进程103调用第二注册接口时，可以创建至少一个消息分发守护线程，可选地，服务进程103创建消息分发守护线程的条数可以通过服务进程103调用第二注册接口的参数进行设定。

需要说明的是，第一注册接口和第二注册接口可以为不同注册接口，也可以为同一注册接口。在第一注册接口和第二注册接口为同一注册接口时，服务进程103在第一次调用该注册接口时，可以创建进程间通信守护线程，在非第一次调用该注册接口时，可以创建消息分发守护线程。

具体地，在微内核操作系统10初始化时(即服务进程103初始化时)，服务进程103可以根据服务进程103对应的设备的类型，调用一次第一注册接口，以创建进程间通信守护线程104，并调用至少一次第二注册接口，以创建至少一个消息分发守护线程。

另外，需要说明的是，服务进程103还可以调用一次第三注册接口，以创建服务进程103的进程间通信通道(即服务进程103的ID值)，以使微内核102可以根据用户进程101发送的请求消息中的服务进程103的ID值，将请求消息发送至服务进程103的进程间通信守护线程104。

此外，还需要说明的是，在仅有一个设备时，微内核操作系统的进程间通信下可以挂载一个设备节点(node)，在存在多个设备时，微内核操作系统的进程间通信下可以挂载多个设备节点(node)。其中，每个设备节点(node)对应一个进程间通信守护线程和至少一个消息分发守护线程。

本实施例中，服务进程可以在初始化时通过调用第一注册接口和第二注册接口创建符合对应的设备的特性的进程间通信守护线程和消息分发守护线程，以便于后续进程间通信守护线程可以对请求消息进行快速分发处理，以及消息分发守护线程按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。相较于现有技术中的微内核操作系统(如QNX操作系统)需要服务进程预先创建大量的线程以便处理请求消息而言，本申请的微内核操作系统减少了需要创建的线程的数量，进而减少了微内核操作系统的开销。解决了现有技术中的微内核操作系统的服务进程需要预先创建大量的线程以便在需要处理大量请求消息可以及时处理，导致微内核操作系统存在开销大的技术问题。另外，本申请无需设置互斥锁，通过对请求消息的分操作行为类型、分优先级的处理，即可解决多线程并发访问设备的问题，降低了微内核操作系统的开发复杂度。

下面通过实施例三对服务进程103对应的设备的类型为串行执行类型时，服务进程103创建进程间通信守护线程104和消息分发守护线程105的情况进行说明。

本实施例应用于图1所示的微内核操作系统的结构示意图。

在服务进程103对应的设备的类型为串行执行类型的条件下，当微内核操作系统10初始化时，服务进程103可以根据服务进程103对应的设备的类型，调用一次第一注册接口，以创建进程间通信守护线程104，并调用一次第二注册接口，以创建一个消息分发守护线程。

在服务进程103仅创建一个消息分发守护线程的情况下，由于设备为串行执行类型，所有消息皆需要串行执行，因此进程间通信守护线程104在接收到微内核102发送的请求消息时，可以将请求消息保存在消息分发守护线程105所使用的请求消息列表中。消息分发守护线程105按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息对服务进程103对应的设备进行访问处理。

需要说明的是，消息分发守护线程105在根据请求消息对服务进程103对应的设备进行访问之后，还可以将访问设备的结果通过微内核102反馈给用户进程101。

举例来说，当设备为串行外设接口(Serial Peripheral Interface，简称SPI)设备时，由于该设备只能串行执行请求，因此在微内核操作系统10初始化时，SPI设备对应的服务进程103调用一次第一注册接口，以创建一个进程间通信守护线程104，并调用一次第二注册接口，以创建一个消息分发守护线程。在进程间通信守护线程104接收到微内核102发送的请求消息时，将请求消息发送到消息分发守护线程105对应的请求消息列表中。消息分发守护线程105按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息对服务进程103对应的设备进行访问处理。

本实施例中，当设备的类型为串行执行类型时，服务进程可以调用一次第一注册接口以创建一个进程间通信守护线程，并调用一次第二注册接口以创建一个消息分发守护线程。相较于现有技术需要为每一条请求消息提供一条线程，即需要微内核操作系统中的服务进程预先创建大量的线程以便在面对大量的请求消息时可以及时处理，导致微内核操作系统存在开销大的问题而言，本申请只需要两条线程即可实现对消息的处理，减少了线程开销。另外，相较于现有技术需要设置互斥锁或者先入先出队列以避免出现线程抢夺资源导致开发复杂度高以及容易出现死锁问题而言，本申请无需设置互斥锁，所有请求消息皆由一个消息分发守护线程按照请求消息的优先级处理，从而在避免出现多个线程抢夺资源的情况，在降低服务进程的开发复杂度的同时，保证了更高优先级的请求消息能够得到更快的响应。

下面通过实施例四对服务进程对应的设备的类型为可并发执行类型时，服务进程创建进程间通信守护线程和消息分发守护线程的情况进行说明。

图2为本申请实施例四提供的一种微内核操作系统的结构示意图。参见图2，该微内核操作系统20包括：用户进程201、微内核202以及服务进程203。

在本实施例中，服务进程203包括进程间通信守护线程204和消息分发守护线程(图2示出了两个消息分发守护线程，分别为消息分发守护线程205和消息分发守护线程206)。

在服务进程203对应的设备的类型为可并发执行类型的条件下，当微内核操作系统20初始化时，服务进程203可以根据服务进程203对应的设备的类型，调用一次第一注册接口，以创建进程间通信守护线程204，并调用两次第二注册接口，每次调用第二注册接口的线程创建个数设定为1，以创建两个消息分发守护线程——消息分发守护线程205(dispatch out)和消息分发守护线程206(dispatch in)。其中，消息分发守护线程205负责处理读取请求，消息分发守护线程206负责处理写入请求。

进程间通信守护线程204在接收到微内核202发送的请求消息时，对请求消息进行解析处理，确定请求消息的操作行为类型是读取类型还是写入类型。在进程间通信守护线程204确定请求消息的操作行为类型后，可以将请求消息发送至与请求消息的操作行为类型对应的消息分发守护线程所共用的请求消息列表中。

举例来说，当进程间通信守护线程204确定请求消息的操作行为类型为读取类型时，可以将请求消息发送至消息分发守护线程205使用的请求消息列表中。消息分发守护线程205按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息对服务进程203对应的设备进行访问处理。

需要说明的是，消息分发守护线程205在根据请求消息对服务进程203对应的设备进行访问之后，还可以将访问设备的结果通过微内核202反馈给用户进程201。

以设备为控制器域网(Controller Area Network，简称CAN)设备为例，由于该设备可以并发执行请求，因此在微内核操作系统20初始化时，CAN设备对应的服务进程203调用一次第一注册接口创建一个进程间通信守护线程204，并调用两次第二注册接口创建两个消息分发守护线程(分别为消息分发守护线程205和消息分发守护线程206)。其中，消息分发守护线程205负责按照请求消息的优先级处理读取请求，消息分发守护线程206负责按照请求消息的优先级处理写入请求。在进程间通信守护线程204对请求消息进行解析，确定请求消息的操作行为类型为写入类型时，可以将请求消息发送至消息分发守护线程206使用的请求消息列表。消息分发守护线程206按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程203对应的CAN设备执行写入处理。

本实施例中，当设备的类型为可并发执行类型时，服务进程可以调用一次第一注册接口以创建一个进程间通信守护线程，并调用两次第二注册接口以创建两个消息分发守护线程。相较于现有技术的微内核操作系统(如QNX操作系统)需要为每一条请求消息提供一条线程，需要预先创建大量的线程以便在面对大量的请求消息时可以处理，导致微内核操作系统存在开销大而言，本申请的微内核操作系统只需要三条线程即可实现对消息的处理，减少了线程开销。另外，相较于现有技术的微内核操作系统需要设备互斥锁或者先入先出队列以避免出现线程抢夺资源导致开发复杂度高以及容易出现死锁问题而言，本申请的微内核操作系统中，一个消息分发守护线程仅处理读取请求，另一个消息分发守护线程仅处理写入请求，且每个消息分发守护线程在处理请求消息时，皆按照优先级处理，在保证消息处理的时效性的同时，无需设置互斥锁或者先入先出队列，即可避免出现线程抢夺资源的问题，降低了服务进程的开发复杂度。

另外，还需要说明的是，基于上述实施例，本申请可以灵活兼容SPI等串行设备以及可并行访问的设备驱动。

下面通过实施例五对服务进程对应的设备的类型为可并发执行类型时，服务进程创建进程间通信守护线程和消息分发守护线程的另一种情况进行说明。

图3为本申请实施例五提供的一种微内核操作系统的结构示意图。参见图3，该微内核操作系统30包括：用户进程301、微内核302以及服务进程303。

在本实施例中，服务进程303包括进程间通信守护线程304和消息分发守护线程(图3示出了三个消息分发守护线程，分别为消息分发守护线程305、消息分发守护线程306以及消息分发守护线程307)。

由于服务进程303对应的设备处理请求消息较为频繁，且处理写入请求的次数大于处理读取请求的次数，因此在服务进程303对应的设备的类型为可并发执行类型的条件下，当微内核操作系统30初始化时，服务进程303可以根据服务进程303对应的设备的类型，调用一次第一注册接口，以创建进程间通信守护线程304，并调至少一次第二注册接口，以创建三个消息分发守护线程。三个消息分发守护线程分别为消息分发守护线程305(dispatch out)、消息分发守护线程306(dispatch in)以及消息分发守护线程307(dispatch in)。其中，消息分发守护线程305负责处理读取请求，消息分发守护线程306负责处理写入请求，消息分发守护线程307负责处理写入请求。可以理解地，在调用至少一次第二注册接口以创建三个消息分发守护线程的过程中，服务进程303创建消息分发守护线程的条数可以通过服务进程303调用第二注册接口的参数进行设定。可选地，可以将线程创建个数设定为3，即调用一次第二注册接口即可完成三个消息分发守护线程的创建。可选地，可以将线程创建个数设定为1，即调用三次第二注册接口即可完成三个消息分发守护线程的创建。

进程间通信守护线程304在接收到微内核302发送的请求消息时，对请求消息进行解析处理，确定请求消息的操作行为类型是读取类型还是写入类型。在进程间通信守护线程304确定请求消息的操作行为类型为写入类型后，可以将请求消息保存在消息分发守护线程306和消息分发守护线程307所共用的请求消息列表中。

另外，需要说明的是，当服务进程303对应设备处理请求消息较为频繁时，服务进程303可以在创建消息分发守护线程时调用第二注册接口以创建至少四个消息分发守护线程。本申请实施例不对创建消息分发守护线程的数量进行限定，可视具体情况而定。

本实施例中，当设备的类型为可并发执行类型时，服务进程可以调用一次第一注册接口以创建一个进程间通信守护线程，并调用第二注册接口以创建三个消息分发守护线程。相较于现有技术的微内核操作系统(如QNX操作系统)需要为每一条请求消息提供一条线程，需要预先创建大量的线程以便在面对大量的请求消息时可以处理，导致微内核操作系统存在开销大而言，本申请的微内核操作系统需要的线程数量相对较少，减少了线程开销。另外，本申请中每个消息分发守护线程在处理请求消息时，皆按照优先级处理，保证消息处理的时效性。

图4为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例一的流程示意图。该方法实施例可以应用于上述图1或者图2所示的服务进程，其中，服务进程包括进程间通信守护线程和消息分发守护线程。如图4所示，该微内核操作系统的进程间消息的处理方法具体包括如下步骤：

步骤S401：进程间通信守护线程通过微内核接收用户进程发送的请求消息。

其中，请求消息为用户进程生成并设置优先级的请求消息。

步骤S402：进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息保存到与请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表。

步骤S403：消息分发守护线程按照消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。

在本实施例中，进程间通信守护线程通过微内核接收用户进程发送的由用户进程生成并设置优先级的请求消息。进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息分发给与请求消息的操作行为类型绑定的消息分发守护线程。在进程间通信守护线程对请求消息的分发中，进程间通信守护线程会将请求消息保存到与请求消息的操作行为类型对应的请求消息列表中，并唤醒绑定在与请求消息的操作行为类型对应的所有消息分发守护线程中的一个消息分发守护线程，该被唤醒的消息分发守护线程用于按照请求消息列表中请求消息的优先级从高到低的顺序，取出优先级最高的请求消息对服务进程对应的设备进行访问处理。相较于现有技术中，微内核操作系统的服务进程需要预先创建大量线程以便处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高而言，本申请仅需借助进程间通信守护线程和分发守护线程，即可实现对大量请求消息的处理，降低了微内核操作系统的开销。另外，本申请无需设置互斥锁，通过对请求消息的分操作行为类型、分优先级的处理，即可解决多线程并发访问设备的问题，降低了微内核操作系统的开发复杂度。

图5为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例二的流程示意图。该方法实施例可以应用于上述图1或者图2所示的服务进程，其中，服务进程包括进程间通信守护线程和消息分发守护线程。如图5所示，该微内核操作系统的进程间消息的处理方法具体包括如下步骤：

步骤S501：服务进程根据设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建进程间通信守护线程和至少一个消息分发守护线程。

需要说明的是，服务进程需要先调用至少一次第二注册接口，以创建消息分发守护线程，再调用一次第一注册接口，以创建进程间通信守护线程，即服务进程需要在创建进程间通信守护线程之前，创建消息分发守护线程，以使得进程间通信守护线程在创建完成时，即可对请求消息进行接收和解析。

步骤S502：进程间通信守护线程通过微内核接收用户进程发送的请求消息。

其中，请求消息为用户进程生成并设置优先级的请求消息。

步骤S503：进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息保存到与请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表。

步骤S504：消息分发守护线程按照消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。

步骤S505：消息分发守护线程将访问设备的结果通过微内核反馈给用户进程。

本实施例中，服务进程可以在初始化时通过第一注册接口和第二注册接口创建符合对应的设备的特性的进程间通信守护线程和消息分发守护线程，以便于后续进程间通信守护线程可以对请求消息进行快速分发处理，以及消息分发守护线程按照请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。相较于现有技术中，微内核操作系统的服务进程需要预先创建大量线程以处理请求消息，还需要设置互斥锁以解决多线程并发访问设备的问题，导致微内核操作系统存在开销大、开发复杂度高而言，本申请仅需借助一个进程间通信守护线程和至少一个分发守护线程，即可实现对大量请求消息的处理，降低了微内核操作系统的开销。另外，本申请无需设置互斥锁，通过对请求消息的分操作行为类型、分优先级的处理，即可解决多线程并发访问设备的问题，降低了微内核操作系统的开发复杂度。

图6为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例三的流程示意图。该方法实施例可以应用于上述图1所示的服务进程。

步骤S601：服务进程调用一次第二注册接口，以创建一个消息分发守护线程。

步骤S602：服务进程调用一次第一注册接口，以创建一个进程间通信守护线程。

步骤S603：进程间通信守护线程通过微内核接收用户进程发送的请求消息。

其中，请求消息为用户进程生成并设置优先级的请求消息。

步骤S604：进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息保存到与请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表。

步骤S605：消息分发守护线程按照消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。

本实施例中，当设备的类型为串行执行类型时，服务进程可以调用一次第一注册接口以创建一个进程间通信守护线程，并调用一次第二注册接口以创建一个消息分发守护线程。相较于现有技术需要为每一条请求消息提供一条线程，即需要微内核操作系统中的服务进程预先创建提供大量的线程以处理请求消息，导致微内核操作系统存在开销大而言，本申请只需要两条线程即可实现对消息的处理，减少了线程开销。另外，相较于现有技术需要设置互斥锁或者先入先出队列以避免出现线程抢夺资源导致开发复杂度高以及容易出现死锁问题而言，本申请中，所有请求消息皆由微内核操作系统的一个消息分发守护线程按照请求消息的优先级处理，避免出现多个线程抢夺资源的情况，降低了服务进程的开发复杂度。

图7为本申请提供的一种微内核操作系统的进程间消息的处理方法实施例四的流程示意图。该方法实施例可以应用于上述图2所示的服务进程。

步骤S701：服务进程调用至少一次第二注册接口，以创建至少一个消息分发守护线程。

其中，创建消息分发守护线程的个数可通过第二注册接口进行设定。

步骤S702：服务进程调用一次第一注册接口，以创建一个进程间通信守护线程。

步骤S703：进程间通信守护线程通过微内核接收用户进程发送的请求消息。

其中，请求消息为用户进程生成并设置优先级的请求消息。

步骤S704：进程间通信守护线程对请求消息进行解析处理，确定请求消息的操作行为类型，并将请求消息保存到与请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表。

步骤S705：消息分发守护线程按照消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对服务进程对应的设备进行访问处理。

本实施例中，当设备的类型为可并发执行类型时，服务进程可以调用一次第一注册接口以创建一个进程间通信守护线程，并调用至少一次第二注册接口以创建至少一个消息分发守护线程。相较于现有技术的微内核操作系统的服务进程需要为每一条请求消息提供一条线程，即需要预先创建大量的线程以处理请求消息，导致微内核操作系统存在开销大而言，本申请的微内核操作系统只需要少量线程即可实现对消息的处理，减少了线程开销。另外，相较于现有技术的微内核操作系统(如QNX)需要设备互斥锁或者先入先出队列以避免出现资源抢夺导致开发复杂度高以及容易出现死锁问题而言，本申请中，可以将串行执行的请求消息放到一个消息分发守护线程使用的请求消息列表中，将可以并发执行的请求消息放到其他消息分发守护线程使用的请求消息列表中，每个消息分发守护线程在处理请求消息时，皆按照优先级处理，在保证消息处理时效性的同时，降低了服务进程的开发复杂度。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种微内核操作系统，包括用户进程、微内核以及服务进程，其特征在于，所述服务进程包括进程间通信守护线程和消息分发守护线程；其中，

所述进程间通信守护线程，用于通过所述微内核接收所述用户进程发送的请求消息；其中，所述请求消息为所述用户进程生成并设置优先级的请求消息；

所述进程间通信守护线程，还用于对所述请求消息进行解析处理，确定所述请求消息的操作行为类型，并将所述请求消息保存到与所述请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表；

所述消息分发守护线程，用于按照所述消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对所述服务进程对应的设备进行访问处理。

2.根据权利要求1所述的微内核操作系统，其特征在于，

所述服务进程，用于根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程。

3.根据权利要求2所述的微内核操作系统，其特征在于，当所述设备的类型为串行执行类型时，所述服务进程，具体用于：

调用一次所述第二注册接口，以创建一个消息分发守护线程；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

4.根据权利要求2所述的微内核操作系统，其特征在于，当所述设备的类型为可并发执行类型时，所述服务进程，具体用于：

调用至少一次所述第二注册接口，以创建至少一个消息分发守护线程；其中，创建消息分发守护线程的个数可通过所述第二注册接口进行设定；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

5.根据权利要求1-4任一项所述的微内核操作系统，其特征在于，所述消息分发守护线程，还用于将访问所述设备的结果通过所述微内核反馈给所述用户进程。

6.一种微内核操作系统的进程间消息的处理方法，其特征在于，应用于服务进程，所述服务进程包括进程间通信守护线程和消息分发守护线程，所述方法包括：

所述进程间通信守护线程通过微内核接收用户进程发送的请求消息；其中，所述请求消息为所述用户进程生成并设置优先级的请求消息；

所述进程间通信守护线程对所述请求消息进行解析处理，确定所述请求消息的操作行为类型，并将所述请求消息保存到与所述请求消息的操作行为类型对应的消息分发守护线程使用的请求消息列表；

所述消息分发守护线程按照所述消息分发守护线程使用的请求消息列表中请求消息的优先级从高到低的顺序，依次根据请求消息，对所述服务进程对应的设备进行访问处理。

7.根据权利要求6所述的微内核操作系统的进程间消息的处理方法，其特征在于，还包括：

所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程。

8.根据权利要求7所述的微内核操作系统的进程间消息的处理方法，其特征在于，当所述设备的类型为串行执行类型时，所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程，具体包括：

调用一次所述第二注册接口，以创建一个消息分发守护线程；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

9.根据权利要求7所述的微内核操作系统的进程间消息的处理方法，其特征在于，当所述设备的类型为可并发执行类型时，所述服务进程根据所述设备的类型，调用一次第一注册接口和至少一次第二注册接口，以创建所述进程间通信守护线程和至少一个消息分发守护线程，具体包括：

调用至少一次所述第二注册接口，以创建至少一个消息分发守护线程；其中，创建消息分发守护线程的个数可通过所述第二注册接口进行设定；

调用一次所述第一注册接口，以创建一个进程间通信守护线程。

10.根据权利要求6-9任一项所述的微内核操作系统的进程间消息的处理方法，其特征在于，还包括：

所述消息分发守护线程将访问所述设备的结果通过所述微内核反馈给所述用户进程。

Images