System service calling method and related device

Abstract

The invention provides a system service calling method which is applied to a kernel under a microkernel architecture. In the system service calling method, when a kernel obtains a request of calling a certain system service for the first time by a thread, the kernel establishes connection with an execution entity of the system service and calls the execution entity to process the request, and after the execution entity finishes processing of the request, the execution entity calls the execution entity to process the request. The kernel does not clean the connection with the execution entity, but updates the state of the execution entity to a hosted state, thereby retaining the correspondence between the thread and the execution entity. Thus, when the thread continues to call the system service next time, the kernel can quickly call the execution entity in the hosting state to process the request of the thread based on the reserved corresponding relation and the connection between the kernel and the execution entity, and therefore the efficiency of calling the system service by the thread is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, to a system service calling method and related apparatus. BACKGROUND

[0002] Micro kernel architecture and monolithic kernel architecture are two main forms of current operating system kernel architecture. Compared with monolithic kernel architecture which adopts a kernel to provide all operating system functions, micro kernel architecture follows the minimization principle, and the kernel only provides the most necessary functions (such as interrupt management, exception management, memory mapping management, inter-process communication, etc.), and a large number of functions (such as process management, memory management, file system, etc.) are provided by various system services.

[0003] Since the micro kernel architecture isolates most of the system services from the kernel, the stability of the entire operating system will not be affected when the system services have errors. Moreover, the system services isolated from the kernel are usually implemented in a non-privileged space, so that the system services can be developed, tested and updated independently, thereby ensuring that the operating system has high maintainability and security under the micro kernel architecture.

[0004] However, since most of the system services are isolated from the kernel under the micro kernel architecture, the application program often needs to perform more steps when calling the system services through the kernel, resulting in low efficiency of the application program calling the system services. SUMMARY

[0005] The present application provides a system service calling method, which can improve the efficiency of thread calling system services.

[0006] The first aspect of the present application provides a system service calling method, which is applied to a kernel under a micro kernel architecture. Specifically, the system service calling method comprises: when a first calling request from a first thread is obtained, the kernel calls an execution entity to process the first calling request by establishing a connection with the first system service, and records the corresponding relationship between the first thread and the execution entity, so as to accurately return the processing result to the first thread when the processing result returned by the execution entity is obtained. Wherein, the first calling request is used to request to call the first system service.

[0007] When the execution entity completes processing of the first invocation request and returns a processing result, the kernel returns the processing result to the first thread and updates the state of the execution entity to a managed state. The connection between the execution entity in the managed state and the kernel is not cleaned up. That is, the kernel does not clean up the connection between the kernel and the execution entity, nor release the execution entity to the resource pool, but updates the state of the execution entity to the managed state. The connection between the execution entity in the managed state and the kernel is not cleaned up, but remains. When the execution entity is in the managed state, the kernel will manage the execution entity and retain the correspondence between the first thread and the execution entity, so that the execution entity can only be invoked by the first thread, and cannot be invoked by other threads.

[0008] Secondly, when the second invocation request from the first thread is obtained, the kernel invokes the execution entity based on the correspondence and the connection to process the second invocation request, the second invocation request being used to request invocation of the first system service. That is, the kernel can determine, based on the retained correspondence between the first thread and the execution entity, that the first thread currently corresponds to the execution entity of the first system service in the managed state. In this way, the kernel does not need to find other execution entities of the first system service to process the second invocation request, but directly invokes the execution entity based on the connection between the kernel and the execution entity in the managed state to process the second invocation request, so that the kernel invokes the execution entity in a manner close to direct invocation, rather than in an Inter Process Communication (IPC) manner.

[0009] In the present scheme, when the kernel obtains a request for a thread to first invoke a system service, the kernel establishes a connection with an execution entity of the system service and invokes the execution entity to process the request. After the execution entity completes processing of the request, the kernel does not clean up the connection with the execution entity, but updates the state of the execution entity to a managed state, thereby retaining the correspondence between the thread and the execution entity. In this way, when the thread next continues to invoke the system service, the kernel can quickly invoke the execution entity in the managed state based on the retained correspondence and the connection with the execution entity to process the request of the thread, so that the kernel invokes the execution entity in a manner close to direct invocation, rather than in an IPC manner, thereby improving the efficiency of the thread invoking the system service.

[0010] In a possible implementation, after returning the processing result to the first thread, the kernel can update the state of the first thread to a corresponding managed entity state, where the corresponding managed entity state is used to indicate that the first thread has a corresponding managed execution entity. In this way, when the second invocation request from the first thread is obtained, based on the state of the first thread (i.e., the corresponding managed entity state), the kernel can quickly determine that the execution entity in the managed state currently needs to be invoked to process the second invocation request, without the need to find or create other execution entities to process the second invocation request.

[0011] In this solution, by updating the state of the first thread to the corresponding managed entity state, the kernel can quickly determine whether the first thread currently has an execution entity in the managed state when the invocation request from the first thread is obtained, and then determine whether to directly invoke the managed execution entity or find or create other execution entities, thereby improving the invocation efficiency of the system service.

[0012] In a possible implementation, when the third invocation request from the first thread is obtained, the kernel cleans up the connection between the execution entity and the first thread and updates the state of the execution entity to a sleep waiting state, where the third invocation request is used to request invocation of a second system service, and the execution entity in the sleep waiting state can be invoked by other threads.

[0013] Then, the kernel invokes the execution entity of the second system service to process the third invocation request by establishing a connection with the execution entity of the second system service, and records the correspondence between the first thread and the execution entity of the second system service. That is, for the third invocation request to invoke the second system service, since the first thread currently does not have a corresponding execution entity of the second system service in the managed state, the kernel needs to find or create an execution entity of the second system service to process the third invocation request.

[0014] In this solution, in the case that a thread has a corresponding execution entity of a system service in a managed state, when the thread requests invocation of another system service, the kernel triggers cleaning up the connection between the execution entity in the managed state and the thread and releasing the execution entity, and establishes a connection with an execution entity of the other system service based on the new invocation request to invoke the execution entity of the other system service to process the invocation request of the thread, thereby ensuring normal invocation of the system service and avoiding resource waste caused by too many execution entities in the managed state corresponding to the same thread.

[0015] In a possible implementation, when the fourth invocation request from the first thread is obtained, if the execution entity is unavailable, the kernel cleans up the connection between the execution entity and the first thread and updates the state of the execution entity to a sleep waiting state, where the fourth invocation request is used to request invocation of the first system service.

[0016] Then, the other execution entity is invoked to process the fourth invocation request by establishing a connection with the other execution entity of the first system service, and the correspondence between the first thread and the other execution entity is recorded.

[0017] That is, if the execution entity of a system service in a managed state is unavailable, the kernel can release the execution entity in the managed state, establish a connection with other execution entities of the same system service, and invoke the other execution entities to process the invocation request of the thread, so as to ensure that the invocation request sent by the thread can be normally processed, and ensure the normal invocation of the system service.

[0018] In the case where the execution entity of the first system service is unavailable, since the process overhead of notifying that the execution entity cannot continue to execute on the current processor is close to the process overhead of re-invoking a new execution entity, in the present solution, the execution entity in the managed state is released, and a new execution entity is re-invoked based on the invocation request for processing, so as to minimize the modification to the prior art, and improve the realizability and compatibility of the present solution.

[0019] In a possible implementation, the first thread corresponds to one managed execution entity at the same time. That is, at the same time, the kernel only manages one execution entity for the first thread, and does not manage multiple different execution entities for the first thread.

[0020] In the present solution, by setting that the kernel only manages one execution entity for one thread at the same time, it can be ensured that the system service invocation efficiency is high, and the system complexity and the processing resources occupied by the system are minimized.

[0021] In a possible implementation, the first system service is in a privileged state or a non-privileged state.

[0022] In a possible implementation, the connection between the execution entity and the kernel is an InterProcess Communication (IPC) connection.

[0023] In a possible implementation, the first system service is configured to provide any one or more of the following functions: process management, memory management, file system, device driver, and network service.

[0024] The second aspect of the present application provides a system service invocation apparatus applied to a kernel in a micro-kernel architecture, and the system service invocation apparatus comprises a transceiving module and a processing module.

[0025] When the transceiving module obtains the first invocation request from the first thread, the processing module is configured to invoke the execution entity to process the first invocation request by establishing a connection with the execution entity of the first system service, and record a correspondence between the first thread and the execution entity, wherein the first invocation request is configured to request invocation of the first system service.

[0026] When the execution entity returns the processing result, the transceiving module is configured to return the processing result to the first thread, and the processing module is further configured to update a state of the execution entity to a hosting state, wherein the connection between the execution entity in the hosting state and the kernel is not cleaned up.

[0027] When the transceiving module obtains the second invocation request from the first thread, the processing module is further configured to invoke the execution entity to process the second invocation request based on the correspondence and the connection, wherein the second invocation request is configured to request invocation of the first system service.

[0028] In a possible implementation, after the transceiving module returns the processing result to the first thread, the processing module is further configured to update a state of the first thread to a corresponding hosting entity state, wherein the corresponding hosting entity state is configured to indicate that the first thread has a corresponding hosted execution entity.

[0029] When the transceiving module obtains the second invocation request from the first thread, the processing module is further configured to determine to invoke the execution entity in the hosting state to process the second invocation request based on the state of the first thread.

[0030] In a possible implementation, when the transceiving module obtains the third invocation request from the first thread, the processing module is further configured to clean up the connection with the execution entity and update a state of the execution entity to a hibernation waiting state, wherein the third invocation request is configured to request invocation of a second system service, and the execution entity in the hibernation waiting state can be invoked by other threads.

[0031] The processing module is further configured to invoke the execution entity of the second system service to process the third invocation request by establishing a connection with the execution entity of the second system service, and record a correspondence between the first thread and the execution entity of the second system service.

[0032] In a possible implementation, when the transceiving module obtains the fourth invocation request from the first thread, if the execution entity is unavailable, the processing module is further configured to clean up the connection with the execution entity and update a state of the execution entity to a hibernation waiting state, wherein the fourth invocation request is configured to request invocation of the first system service.

[0033] The processing module is further configured to invoke another execution entity to process the fourth invocation request by establishing a connection with the other execution entity of the first system service, and record a correspondence between the first thread and the other execution entity.

[0034] In a possible implementation, the first thread corresponds to one managed execution entity at the same time.

[0035] In a possible implementation, the first system service is in a privileged state or a non-privileged state.

[0036] In a possible implementation, the connection between the execution entity and the kernel is an IPC connection.

[0037] In a possible implementation, the first system service is configured to provide any one or more of the following functions: process management, memory management, file system, device driver, and network service.

[0038] The third aspect of the present application provides a system service calling apparatus, which can include a processor, the processor and a memory are coupled, and the memory stores program instructions. When the program instructions stored in the memory are executed by the processor, the method of the first aspect or any implementation manner of the first aspect is implemented. For the processor to execute the steps in each possible implementation manner of the first aspect, specific details can be referred to the first aspect, which will not be repeated here.

[0039] The fourth aspect of the present application provides a computer readable storage medium, and the computer readable storage medium stores a computer program. When the computer program is run on a computer, the computer is caused to execute the method of any implementation manner of the first aspect.

[0040] The fifth aspect of the present application provides a circuit system, and the circuit system includes a processing circuit. The processing circuit is configured to execute the method of any implementation manner of the first aspect.

[0041] The sixth aspect of the present application provides a computer program product, and when the computer program product is run on a computer, the computer is caused to execute the method of any implementation manner of the first aspect.

[0042] The seventh aspect of the present application provides a chip system, and the chip system includes a processor. The processor is configured to support the server to implement the functions involved in any implementation manner of the first aspect, for example, process the data and / or information involved in the above method. In a possible design, the chip system further includes a memory. The memory is configured to save necessary program instructions and data of the server. The chip system can be composed of a chip, or can include the chip and other discrete devices.

[0043] The advantages of the above-mentioned second aspect to seventh aspect can refer to the introduction of the first aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1A comparison diagram of application program calling system service in a single kernel architecture and a microkernel architecture of the related art;

[0045] Figure 2 A diagram of a system architecture provided in the present application;

[0046] Figure 3 A diagram of a structure of an execution device 101 provided in the present application;

[0047] Figure 4 A flow diagram of a calling method of a system service provided in the present application;

[0048] Figure 5 A diagram of an application scenario of the calling method of the system service provided in the present application;

[0049] Figure 6 A comparison diagram of thread calling system service in a microkernel architecture provided in the present application;

[0050] Figure 7 A flow diagram of thread calling system service provided in the present application;

[0051] Figure 8 A flow diagram of thread calling system service in different situations provided in the present application;

[0052] Figure 9 A diagram of a thread state machine and a state machine of an execution entity of system service provided in the present application;

[0053] Figure 10 A diagram of a relationship among thread, kernel and execution entity provided in the present application;

[0054] Figure 11 A diagram of a structure of a calling device of system service provided in the present application;

[0055] Figure 12 A diagram of a structure of an electronic device provided in the present application;

[0056] Figure 13 A diagram of a structure of a computer readable storage medium provided in the present application. DETAILED DESCRIPTION

[0057] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments of the present application.

[0058] The terms "first", "second", "third", "fourth", and the like in the description and in the claims of the present application, and above-mentioned drawings (if there are) are used to distinguish similar objects, and do not necessarily have to be used to describe a particular order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.

[0059] In addition, the terms "comprising" and "having" and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device containing a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0060] For ease of understanding, some technical terms related to the embodiments of the present application are introduced first.

[0061] (1) Microkernel architecture

[0062] The microkernel architecture is a kernel architecture of an operating system. The typical feature of the microkernel architecture is that the kernel only retains the most basic and core operating system functions (such as interrupt management, exception management, memory mapping management, inter-process communication, etc.), and the remaining functions (such as process management, memory management, file system, etc.) are implemented in the form of system services.

[0063] (2) Monolithic kernel architecture

[0064] The monolithic kernel architecture is a kernel architecture of an operating system. Compared with the microkernel architecture, the typical feature of the monolithic kernel architecture is that all services of the operating system (such as process management, memory management, file system, device driver, network protocol, etc.) run in the same space and in the same privileged state.

[0065] (3) System service

[0066] The system service refers to a program, routine or process that performs a specified system function to support other programs to obtain system functions. In a microkernel system, a system service is usually responsible for providing a specific function (such as process management, memory management, file system, device driver, network protocol, etc.), and the system service is usually located in a different privileged state from the microkernel itself.

[0067] (4) Execution entity

[0068] The execution entity refers to an object that provides services for a user call in a system service. Generally, the execution entity will include a user stack located in the system service and control information located in the kernel.

[0069] (5) Privileged state

[0070] Privileged state refers to the state of the operating system's supervisor runtime, which has a high privilege level. Specifically, if an application runs in the privileged state, the application can access the computer's task resources, i.e., the application's resource access permission is not restricted.

[0071] (6) Non-privileged state

[0072] Non-privileged state, which can also be referred to as user state, refers to the state of the application runtime, which has a low privilege level. Specifically, if an application runs in the non-privileged state, the application's access to resources will be restricted.

[0073] (7) Kernel

[0074] The kernel is the most basic part of the operating system, and is essentially a part of software that provides safe access to computer hardware for numerous applications. The kernel can provide the most basic functions of the operating system and is the basis for the operation of the operating system.

[0075] (8) Inter Process Communication (IPC)

[0076] IPC refers to the communication or exchange of information between different processes.

[0077] (9) Process

[0078] A process is a running activity of a program on a certain data set in a computer, and is the basic unit of resource allocation for the system and the basis of the operating system structure. In the early process-oriented computer structure, the process is the basic execution entity of the program; in the current thread-oriented computer structure, the process is a container of threads. A program refers to the description of instructions, data, and their organization, and a process is the entity of a program.

[0079] (10) Thread

[0080] A thread is the smallest unit of operation that can be scheduled by the operating system. A thread is contained in a process and is the actual operating unit in the process. A thread refers to a single sequential control flow in a process, and a process can have multiple threads running concurrently, each thread performing different tasks in parallel.

[0081] (11) System call

[0082] A system call is a mechanism provided by an operating system to applications to request kernel services. Essentially, a system call is a programming interface provided by an operating system to applications, allowing applications to interact with the kernel of the operating system to access services and resources provided by the operating system. System calls are part of the operating system kernel, and through system calls, applications can perform privileged operations such as file access, process management, and network communication.

[0083] Through research, the applicant found that, compared with a single kernel architecture, a microkernel architecture often has more performance overhead when an application calls a system service, resulting in lower efficiency of the application calling the system service.

[0084] By way of example, please refer to Figure 1 , Figure 1 A comparison diagram of an application calling a system service under a single kernel architecture and a microkernel architecture of the related art. As shown in Figure 1 , under a single kernel architecture, during the running of an application, the thread corresponding to the application enters the kernel through a system call (syscall) or exception, and since all kernel components are located in the same system space and the same privilege state, the kernel can obtain various system services through function calls. In a microkernel system, after the thread corresponding to the application enters the kernel through a syscall or exception, due to the isolation of the kernel and the system service, the system service needs to be obtained through IPC. After the system service is executed, it also needs to be returned to the thread through IPC. Therefore, compared with a single kernel architecture, the thread calls a system service at least twice more, resulting in more work for each same operating system function in a microkernel architecture than in a single kernel architecture.

[0085] Compared with a function call, IPC often has more overhead. Under a microkernel architecture, IPC mainly includes necessary processes such as connection establishment and context switching. Among them, connection establishment includes the following multiple steps: a) authentication, to determine whether the user has the right to call; b) finding or creating an execution entity of the system service; c) recording of the call chain, the kernel needs to record the entire call process, otherwise it cannot be returned; d) synchronizing some connection information to the system service. Context switching includes at least the following two steps: e) general register switching, for example, in the arm64 architecture, 31 general registers need to be saved and restored for each IPC; f) privilege level and address space switching.

[0086] Generally, due to the isolation of most system services from the kernel under the micro-kernel architecture, the thread of an application program often needs to perform multiple steps related to IPC when invoking a system service through the kernel, resulting in low efficiency of the thread of the application program in invoking the system service.

[0087] Therefore, the present application provides a method for invoking a system service. When the kernel obtains a request for a thread to invoke a certain system service for the first time, the kernel establishes a connection with an execution entity of the system service and invokes the execution entity to process the request. After the execution entity completes the processing of the request, the kernel does not clean up the connection with the execution entity but updates the state of the execution entity to a hosting state, thereby preserving the correspondence between the thread and the execution entity. In this way, when the thread continues to invoke the system service next time, the kernel can quickly invoke the execution entity in the hosting state based on the preserved correspondence and the connection with the execution entity to process the request of the thread, thereby improving the efficiency of the thread in invoking the system service. Moreover, the method provided by the present application is applied to the micro-kernel architecture, can maintain the advantages of the micro-kernel architecture, and has universality and good compatibility.

[0088] Please refer to Figure 2 , Figure 2 for a schematic diagram of a system architecture provided by the present application. As shown in Figure 2 , in the system architecture, the execution device 101 may, for example, be a physical host or a physical server or the like. Moreover, the execution device 101 is in communication connection with a data storage system 102, for obtaining program codes stored in the data storage system 102 to implement the method for invoking a system service provided by the present application. The data storage system 102 may, for example, be implemented by a storage device deployed on the execution device 101, for example, the execution device 101 is a physical server and the data storage system 102 is a hard disk deployed on the physical server. The data storage system 102 may, for example, also be implemented by a storage device independent of the execution device, for example, the execution device 101 is a computing server and the data storage system 102 is a data server specially storing program codes.

[0089] During work, the execution device 101 can obtain program codes and related data required by the method for invoking a system service from the data storage system 102, and provide efficiency of a thread in invoking a system service on the execution device 101 based on the method for invoking a system service provided by the present application.

[0090] Please refer to Figure 3 , Figure 3 for a structural schematic diagram of an execution device 101 provided by the present application. As shown in Figure 3As shown, the execution device 101 to which the method of calling the system service provided by the present application is applied includes a processor 103 coupled with a system bus 105. The processor 103 can be one or more processors, each of which can include one or more processor cores. A video adapter 107 can drive a display 109 coupled with the system bus 105. The system bus 105 is coupled with a bus bridge 111 and an input / output (I / O) bus. An I / O interface 115 is coupled with the I / O bus. The I / O interface 115 communicates with various I / O devices, such as an input device 117 (e.g., a touch screen), an external storage 121 (e.g., a hard disk, a floppy disk, an optical disk, or a USB (Universal Serial Bus) drive), a multimedia interface, etc.), a transceiver 123 (which can send and / or receive radio communication signals), a camera 155 (which can capture still and moving digital video images), and an external USB port 125. Among them, the interface connected with the I / O interface 115 can be a USB interface, optionally.

[0091] The processor 103 can be any conventional processor, including a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, or a combination thereof. Optionally, the processor can be a special-purpose device such as an ASIC.

[0092] The execution device 101 can communicate with a software deployment server 149 through a network interface 129. The network interface 129 is an example of a hardware network interface, such as a network card. The network 127 can be an external network such as the Internet, or an internal network such as an Ethernet network or a virtual private network (VPN). Optionally, the network 127 can also be a wireless network such as a WiFi network, a cellular network, etc.

[0093] A hard drive interface 131 is coupled with the system bus 105. The hard drive interface is connected with a hard disk drive 133. A system memory 135 is coupled with the system bus 105. Data running on the system memory 135 can include an operating system (OS) 137 of the execution device 101, an application program 143, and a schedule.

[0094] The operating system includes a shell 139 and a kernel 141. The shell 139 is an interface between a user and the kernel of the operating system. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system: waits for the user's input, interprets the user's input to the operating system, and processes various outputs of the operating system.

[0095] The kernel 141 consists of those parts of the operating system that manage memory, files, peripherals, and system resources. The kernel 141 directly interacts with the hardware, and the operating system kernel usually runs processes and provides inter-process communication, provides CPU time slice management, interrupts, memory management, and IO management, etc.

[0096] Please refer to Figure 4 , Figure 4 A flowchart of a calling method of a system service provided in the present application is shown in FIG. 1. As shown in FIG. 1, the calling method of the system service is applied to a kernel under a microkernel architecture, and specifically includes the following steps 401-403. Figure 4

[0097] Step 401, when a first calling request from a first thread is acquired, a first system service is called by establishing a connection with an execution entity of the first system service to process the first calling request, wherein the first calling request is used to request to call the first system service.

[0098] In the present application, the first thread can be specifically a thread corresponding to an application program of a user running in an execution device, and the present application does not limit the specific form of the first thread. During the running of the first thread, when the first thread needs to call a system service, the first thread can send a first calling request to the kernel in the form of syscall or exception, and the first calling request is used to request to call the first system service.

[0099] ​After the kernel obtains the first invocation request, the kernel checks whether there is a created and idle execution entity of the first system service in the resource pool. If there is a created and idle execution entity of the first system service in the resource pool, the kernel establishes a connection with the execution entity, and invokes the execution entity to process the first invocation request. If there is no created and idle execution entity of the first system service in the resource pool, the kernel first creates an execution entity of the first system service, then establishes a connection with the execution entity and invokes the execution entity to process the first invocation request. The resource pool can be used to store the created and idle execution entity. For any system service, the kernel can create one or more execution entities for the system service in advance, and store the created execution entities in the resource pool, so that the created execution entities can be invoked from the resource pool to process the corresponding invocation request when the system service is invoked subsequently.

[0100] Optionally, the connection between the execution entity of the first system service and the kernel is, for example, an IPC connection.

[0101] Specifically, the kernel can establish a connection with the execution entity of the first system service and invoke the execution entity to process the first invocation request by means of IPC. The process of establishing a connection with the execution entity and invoking the execution entity by means of IPC can refer to the description above, and will not be described here again.

[0102] In addition, when the kernel invokes the execution entity of the first system service to process the first invocation request from the first thread, the kernel needs to record the correspondence between the first thread and the execution entity, so that when the processing result returned by the execution entity is obtained, the processing result can be accurately returned to the first thread.

[0103] Optionally, in the present application, the first system service is, for example, used to provide any one or more of the following functions: process management, memory management, file system, device driver, network service and the like. In general, the first system service can be a system service used to provide any function other than the basic function, and the present application does not make a specific limitation in this regard.

[0104] In step 402, when the execution entity returns the processing result, the processing result is returned to the first thread and the state of the execution entity is updated to a managed state. The connection between the execution entity in the managed state and the kernel will not be cleaned up, and the execution entity has a correspondence with the first thread.

[0105] After the execution entity of the first system service processes the first invocation request, the execution entity can return the processing result to the kernel. After the kernel obtains the processing result returned by the execution entity, the kernel continues to return the processing result to the first thread, so as to realize the whole process of invoking the first system service by the first thread.

[0106] It is worth noting that, in the present application, after the kernel returns the processing result to the first thread, the kernel does not clean up the connection between the kernel and the execution entity, nor does it release the execution entity into the resource pool, but updates the state of the execution entity to a hosting state. The connection between the execution entity in the hosting state and the kernel is not cleaned up, but is maintained. In the case that the execution entity is in the hosting state, the kernel will host the execution entity and maintain the connection with the execution entity, so that the execution entity can only be called by the first thread, and cannot be called by other threads.

[0107] In addition, the kernel also retains the correspondence between the first thread and the execution entity recorded when the kernel calls the execution entity to process the first call request, to indicate that the thread corresponding to the execution entity in the hosting state is the first thread.

[0108] Step 403, when the second call request from the first thread is obtained, the execution entity is called based on the correspondence and the connection to process the second call request, and the second call request is used to request to call the first system service.

[0109] In the present application, the first thread will send a second call request to the kernel to request to call the first system service if it needs to continue to call the first system service. In the case that the kernel updates the state of the execution entity of the first system service to the hosting state, after the kernel obtains the second call request, the kernel can determine that the first thread currently corresponds to the execution entity of the first system service in the hosting state based on the retained correspondence between the first thread and the execution entity. In this way, the kernel does not need to find other execution entities of the first system service to process the second call request, but directly calls the execution entity based on the connection between the kernel and the execution entity in the hosting state to process the second call request, so that the kernel calls the execution entity in a manner close to direct calling, rather than calling the execution entity in the IPC manner.

[0110] That is, after the kernel updates the execution entity of a system service to the hosting state, if the thread corresponding to the execution entity continues to call the same system service, the kernel can directly call the execution entity in the hosting state to process the call request of the thread, without the need to establish a connection with the execution entity based on the conventional IPC manner, thereby omitting multiple steps in the execution entity calling process and improving the calling efficiency of the system service.

[0111] Optionally, after returning the processing result to the first thread in step 402, the kernel can further update the state of the first thread to the corresponding managed entity state, where the corresponding managed entity state is used to indicate that the first thread has a corresponding managed execution entity. That is, the state of the first thread and the state of the execution entity corresponding to the first thread are both updated, the state of the first thread is the corresponding managed entity state, and the state of the execution entity corresponding to the first thread is the managed state.

[0112] In this way, when the second call request from the first thread is obtained, based on the state of the first thread (i.e., the corresponding managed entity state), the kernel can quickly determine that the execution entity in the managed state needs to be called to process the second call request, without the need to find or create other execution entities to process the second call request.

[0113] That is, by updating the state of the first thread to the corresponding managed entity state, the kernel can quickly determine whether the first thread currently has a managed execution entity when the call request from the first thread is obtained, and then determine whether to directly call the managed execution entity or find or create other execution entities, thereby improving the call efficiency of the system service.

[0114] Optionally, the first system service described above can be in a privileged state or a non-privileged state. It should be noted that in the current processor instruction set architecture, switching between the non-privileged state and the privileged state often accompanies the actions of processor pipeline emptying and the like, thereby bringing additional overhead. Specifically, switching between the non-privileged state and the privileged state has address space switching overhead. Since in the current processor instruction set architecture, a processor can only run one privileged state address space and one non-privileged state address space at the same time, if a system service is in a non-privileged state, when the kernel calls the system service, the processor needs to replace the address space of the thread calling the system service with the address space of the system service to continue execution. In addition, if a system service is in a privileged state, when the kernel calls the system service, the processor does not need to replace the address space, thereby further saving the overhead of switching between the privileged level and the address space (i.e., the overhead f described above).

[0115] Since each processor corresponds to a register to record which address space the currently running thread belongs to, the address space pointed to by the register corresponding to the processor is referred to as the address space currently running by the processor. That is, the privileged state address space or the non-privileged state address space running by the processor refers to the address space running by the thread or the execution entity currently running by the processor.

[0116] The above introduces that when the execution entity corresponding to the first thread is in the managed state, when the first thread invokes the same system service again, the kernel directly calls the execution entity to process the call request sent by the first thread. In some cases, the execution entity corresponding to the first thread may not be able to be used to process the call request sent by the first thread subsequently, at which time the connection between the kernel and the execution entity can be cleaned up and the execution entity is released to the resource pool, so that the execution entity changes from the managed state corresponding to the first thread to the sleep waiting state.

[0117] In one possible example, after the kernel updates the state of the execution entity of the first system service to the managed state, when a third call request for requesting to call a second system service is obtained from the first thread, the kernel cleans up the connection with the above-mentioned execution entity and updates the state of the execution entity to the sleep waiting state. The execution entity in the sleep waiting state can be called by other threads. That is, the kernel actually cleans up the IPC connection with the execution entity, and releases the execution entity to the resource pool, so that the state of the execution entity changes from the managed state corresponding to the first thread to the sleep waiting state.

[0118] Then, the kernel calls the execution entity of the second system service to process the third call request by establishing a connection with the execution entity of the second system service, and records the correspondence between the first thread and the execution entity of the second system service. That is, for the third call request for calling the second system service, since the first thread currently does not have an execution entity of the second system service in the managed state, the kernel needs to find or create an execution entity of the second system service to process the third call request.

[0119] The kernel calls the execution entity of the second system service to process the third call request by establishing a connection with the execution entity of the second system service, which is similar to the process of the kernel establishing a connection with the execution entity of the first system service and calling the execution entity to process the first call request in the above-mentioned step 401. For details, please refer to the above-mentioned step 401, which will not be described here.

[0120] Similarly, after the execution entity of the second system service processes the third call request and returns the processing result to the kernel, the kernel returns the processing result to the first thread and retains the correspondence between the first thread and the execution entity of the second system service, and updates the state of the execution entity of the second system service to the managed state. In this way, if the first thread continues to request to call the second system service next time, the kernel can also quickly call the execution entity of the second system service corresponding to the first thread to process the request from the first thread.

[0121] In the present solution, when a thread corresponds to an execution entity of a certain system service in a managed state and requests to invoke another system service, the kernel triggers to clean up the connection with the execution entity in the managed state and release the execution entity, and establishes a connection with an execution entity of another system service based on the new invocation request to invoke the execution entity of another system service to process the invocation request of the thread, so as to ensure the normal invocation of the system service and avoid the waste of resources caused by too many execution entities in the managed state corresponding to the same thread.

[0122] In another possible example, after the kernel updates the state of the execution entity of the first system service to the managed state, when the fourth invocation request from the first thread for requesting to invoke the first system service is obtained, if the execution entity is unavailable, the kernel cleans up the connection with the execution entity and updates the state of the execution entity to the sleep waiting state. That is, if the managed execution entity corresponding to the first thread is itself unavailable when the first thread continues to invoke the same system service, the kernel also cleans up the connection with the execution entity currently in the managed state and releases the execution entity.

[0123] Then, the kernel invokes other execution entities to process the fourth invocation request by establishing a connection with other execution entities of the first system service, and records the correspondence between the first thread and other execution entities.

[0124] That is, if the execution entity of a certain system service in the managed state is unavailable, the kernel can release the execution entity in the managed state, and establish a connection with other execution entities of the same system service and invoke other execution entities to process the invocation request of the thread, so as to ensure that the invocation request sent by the thread can be normally processed and ensure the normal invocation of the system service.

[0125] The reason why the execution entity of the first system service is unavailable can be that the current processor is preempted by another execution entity of the first system service, so that all other execution entities of the first system service cannot continue to execute on the current processor at this time. Of course, the execution entity of the first system service can also be unavailable due to other reasons, such as an exception of the execution entity, which is not limited in the present application.

[0126] In the case where the execution entity of the first system service is unavailable, since the process overhead of notifying that the execution entity cannot continue to execute on the current processor is close to the process overhead of re-invoking a new execution entity, the execution entity in the managed state is released and a new execution entity is re-invoked to process based on the invocation request in the present solution, so as to minimize the modification to the prior art and not introduce additional overhead, thereby improving the realizability and compatibility of the present solution.

[0127] Optionally, in the present application, the first thread only corresponds to one hosted execution entity at the same time. That is, the kernel only hosts one execution entity for the first thread at the same time, instead of hosting multiple different execution entities for the first thread at the same time. Generally speaking, the efficiency of the system service call can be effectively improved when the kernel hosts one execution entity for the thread. Compared with the kernel hosting one execution entity for the thread, the kernel hosting multiple execution entities for the thread does not bring further obvious improvement to the efficiency of the system service call. However, compared with the kernel hosting one execution entity for the thread, the kernel hosting multiple execution entities for the thread has relatively high complexity and needs to occupy more processing resources. Therefore, by setting the kernel to host one execution entity for the same thread at the same time, the system complexity and the processing resources occupied by the system can be reduced as much as possible while the efficiency of the system service call is ensured.

[0128] Of course, in some embodiments, the kernel can also host multiple execution entities for the first thread, and the multiple execution entities are execution entities for different system services. In this way, when the first thread repeatedly calls the system service that has been called, the kernel can directly call the execution entity in the hosted state, thereby improving the efficiency of the system service call in various cases.

[0129] The above describes the system service call method provided by the present application. For the sake of understanding, the execution process of the system service call method provided by the present application will be described in detail below with specific examples.

[0130] Please refer to Figure 5 , Figure 5 for a schematic diagram of an application scenario of the system service call method provided by the present application. As shown in Figure 5 , the system service call method provided by the present application is applied to a microkernel architecture, which includes the following three levels of components: a kernel, system services, and user processes. In the microkernel architecture, different application programs at the user level behave as different user processes (for example, user process 1-user process in Figure 5 . One or more threads can run in each user process. The microkernel architecture can include multiple system services, and different system services can be used to provide different system functions, such as the memory management, file system, process management, device driver, and network protocol functions shown in Figure 5 . In addition, the same system service can have one or more execution entities, and the execution entities are responsible for implementing the functions corresponding to the system service.

[0131] Specifically, the entry of threads using all functions of the operating system is triggering a system call (syscall) or an exception handling (exception). After the thread enters the kernel, the kernel determines to handle it by itself or dispatch it to the corresponding system service according to the function requested by the thread. Similarly, after the system service is processed, a dedicated system call is triggered to enter the kernel. The kernel tracks the call relationship between the thread and the system service, and thus the kernel can return the processing result to the thread to make the thread continue to execute.

[0132] Referring to Figure 6 , Figure 6 A comparison diagram of threads calling system services under a microkernel architecture is provided in the present application. As shown in Figure 6 , in the related art, after the thread enters the kernel through syscall or exception, the kernel needs to obtain the system service through IPC. After the system service is executed, the processing result is returned to the kernel through syscall or exception, and then the kernel returns the processing result to the thread through IPC.

[0133] In the scheme provided in the present application, the thread initiates a request to the kernel to obtain the system service, and the kernel still uses the IPC method to provide the system service for the thread. After the system service completes the processing of the request, before entering the kernel from the system service and returning to the thread, the kernel does not release the execution entity and clean up the IPC connection, but hosts the execution entity of the currently used system service.

[0134] In this way, when the thread calls the system service again, it can first enter the kernel through syscall or exception. At this time, the kernel can directly call the hosted execution entity to process the call request sent by the thread, without the need to obtain the system service based on the IPC method, thereby avoiding multiple steps related to IPC.

[0135] The present scheme is a dynamic optimization on the microkernel architecture, rather than a reconstruction of the architecture of the entire system, so it can maintain the advantages of the microkernel architecture and has good compatibility. In the present scheme, all actions are completed in the kernel and the system service, which is transparent to the user-side thread (i.e. without the need to adjust the code of the user-side application), and there is no modification of the portable operating system interface (POSIX) semantic conflict, so it has good universality and implementability.

[0136] Referring to Figure 7 , Figure 7A flowchart of a thread invoking a system service is provided in the present application. As shown in Figure 7 , under a microkernel architecture, the flow of the thread invoking the system service includes the following steps 701-706.

[0137] Step 701, the thread initiates the invocation of the system service for the first time.

[0138] Exemplarily, please refer to Figure 8 , Figure 8 A flowchart of a thread invoking a system service under different conditions is provided in the present application. As shown in Figure 8 , when the thread initiates the invocation of the system service for the first time, the thread can send a request for invoking the system service to the kernel through syscall.

[0139] After receiving the request for invoking the system service sent by the thread, the kernel invokes the execution entity of the system service to process the request for invoking the system service sent by the thread through IPC. Specifically, the kernel finds or creates the execution entity of the system service in the resource pool based on the request for invoking the system service sent by the thread, records the invocation information, and then jumps to the execution entity of the system service to process the request for invoking the system service sent by the thread.

[0140] Since the request for invoking the system service from the thread needs an execution entity of the system service to process each time, and the execution entity of the system service generally represents a user stack and related information of the service call (such as the information of the invoker or the parameters or results of the current call), the kernel can find an execution entity for processing the request for invoking the system service each time it receives the request for invoking the system service from the thread, or create a new execution entity when it cannot find an execution entity for processing the request for invoking the system service in the resource pool. The user stack refers to a piece of area in the system service process space.

[0141] When the kernel invokes an execution entity to handle a call request, it also records the corresponding call information. Specifically, if a thread's call request can be completed by a single system service, the kernel records the call relationship between the thread and the execution entity of the invoked system service. If a thread's call request requires the cooperation of multiple system services, there are further call relationships between the execution entities of these multiple system services. Therefore, the kernel records the call relationships between the thread and the execution entities of the system services, as well as the call relationships between the execution entities of each system service. For example, suppose a thread requests to read a file. It first calls the file system service, and the file system then calls the driver system service to retrieve the data stored on the disk. The call chain is: thread → file system service → driver system service. In this case, the kernel can use a data structure (such as a stack) to record the call chain and thus record the call information.

[0142] Step 702: After the system service is invoked for the first time, the execution entity of the system service is hosted in the kernel.

[0143] like Figure 8 As shown, after the execution entity of the system service completes the processing of the call request, it returns the processing result to the kernel via syscall. At this point, the kernel can mark the execution entity of the system service as managed, that is, it manages the execution entity of the system service in the kernel, and the kernel returns the processing result to the thread via IPC.

[0144] Specifically, in this scheme, a new intermediate state is introduced into both the thread state machine and the state machine of the execution entity of the system service to mark that the execution entity of the system service is in a managed state. Generally, the kernel in a microkernel architecture usually uses a state machine to track the state of threads and various execution entities, and the transition of the state machine is generally synchronized with the change of the call chain.

[0145] For example, please refer to Figure 9 , Figure 9 This is a schematic diagram of a thread state machine and a state machine of an execution entity of a system service, provided in this application. Figure 9 As shown, to implement the kernel-managed execution entity of system services, a new managed entity state (part-inacvt) is introduced for threads, and a new managed state (part-actv) is introduced for the execution entity of system services. The managed entity state and the managed state appear in pairs. When a thread's state is the managed entity state, the execution entity of the corresponding system service is in the managed state.

[0146] exist Figure 9In the thread state machine, three states are included, which are active state, corresponding entity state and inactive state. When the thread does not invoke the system service, the thread is in the inactive state; when the thread sends a call request to the kernel, triggering the system service, the thread changes from the inactive state to the active state; when the kernel manages the execution entity of the corresponding system service for the thread, the thread changes from the active state to the corresponding entity state; when the kernel clears the execution entity of the system service managed by the thread, the thread changes from the corresponding entity state to the inactive state.

[0147] Similarly, in the execution entity state machine of the system service, three states are included, which are active state, managed state and inactive state. When the execution entity of the system service is not invoked, the execution entity of the system service is in the inactive state; when the kernel invokes the execution entity of the system service to process the call request from the thread, the execution entity of the system service changes from the inactive state to the active state; when the kernel manages the execution entity of the corresponding system service for the thread, the execution entity of the system service changes from the active state to the managed state; when the kernel clears the execution entity of the system service managed by the thread, the execution entity of the system service changes from the managed state to the inactive state.

[0148] It should be noted that by introducing new states into the state machine, the kernel can quickly determine how to handle the call request when receiving the call request from the thread. For example, when receiving the call request from the thread, the kernel can check the thread state machine. If the state of the current thread is the inactive state, it means that this call is the first system service call initiated by the thread, so the kernel needs to find or create the execution entity of the corresponding system service to process the call request; if the state of the current thread is the corresponding entity state, it means that the corresponding execution entity has been managed for the thread, so the kernel needs to further determine whether the execution entity managed by the thread is available.

[0149] When the kernel manages the execution entity of the system service, the kernel does not release the execution entity of the system service, nor does it clean up the connection between the kernel and the execution entity of the system service, thereby preserving the correspondence between the thread recorded by the kernel and the execution entity of the system service.

[0150] Among them, for any thread running in the operating system, the kernel can manage a corresponding execution entity for the thread after invoking the corresponding execution entity of the system service for the thread, thereby establishing a management relationship between the thread and the execution entity. Exemplarily, please refer to Figure 10 , Figure 10A schematic diagram of the relationship between a thread, a kernel and an execution entity is provided in the present application. As shown in Figure 10 the kernel can host an execution entity of a corresponding system service uniquely for each thread, so that different threads can have a hosted execution entity after calling a system service.

[0151] Step 703, the thread continues to initiate a call to a system service.

[0152] After the thread obtains the processing result returned by the kernel, the thread can continue to initiate a call to a system service according to actual running needs. The thread can continue to initiate a call to the same system service or initiate a call to a different system service. That is, the system service called by the thread can be the same as or different from the system service called last time.

[0153] Step 704, the kernel judges whether the execution entity hosted by the thread is available.

[0154] Since the kernel has hosted a corresponding execution entity for the thread in step 702, the kernel can further judge whether the execution entity currently hosted for the thread is available based on the reserved call information, so as to determine whether the hosted execution entity can be used to process the call request sent by the thread again.

[0155] There can be two types of reasons why the execution entity hosted for the thread is not available.

[0156] The first type of reason is an active reason: the system service called by the thread this time is different from the system service corresponding to the execution entity hosted for the thread. For example, the system service called by the thread last time is a file system service, so the kernel hosts an execution entity of the file system service for the thread; however, the system service called by the thread this time is a driver system service, and the execution entity hosted for the thread is an execution entity under the file system service, so the execution entity of the file system service hosted by the kernel is not available.

[0157] The second type of reason is a passive reason: the state of the execution entity hosted for the thread changes. For example, the execution entity hosted for the thread itself is abnormal; or there is already an execution entity of the same system service running on the current processor, so that the execution entity hosted cannot continue to run on the current processor.

[0158] Step 705, if the hosted execution entity is available, the kernel uses the hosted execution entity to provide a service.

[0159] As shown in Figure 8As shown, if the managed execution entity is available, the kernel can quickly invoke the managed execution entity (in a manner similar to a function call) to handle the invocation request from the thread, without the need to re-invoke the execution entity to handle the invocation request through IPC.

[0160] It should be noted that, when the execution entity of the kernel hosting the system service for the thread is running in a privileged state, the execution entity of the system service does not need to be invoked to handle the invocation request, without the need to replace the address space corresponding to the process in which the thread is located on the processor with the address space corresponding to the system service, thereby further saving the address space replacement overhead.

[0161] Step 706, if the managed execution entity is not available, the kernel cleans up the managed execution entity, and invokes a new execution entity through IPC to provide services.

[0162] As shown, if the managed execution entity is not available, the kernel needs to clean up the managed execution entity (i.e., clean up the connection relationship between the kernel and the managed execution entity and release the execution entity to the resource pool). Moreover, the kernel also needs to invoke a new execution entity through IPC to handle the invocation request from the thread. Figure 8 It should be noted that, after the kernel invokes the IPC to invoke a new execution entity to complete the invocation request from the thread, the kernel continues to host the new execution entity for the thread, thereby ensuring that the thread can have a managed execution entity as much as possible after each invocation of the system service.

[0163] The above describes the method provided by the present application in detail, and next, the device provided by the present application for executing the above method will be introduced.

[0164] Please refer to

[0165] , Figure 11 FIG. 1 is a structural schematic diagram of a system service invocation device provided by the present application. As shown, the system service invocation device is applied to implement a kernel under a micro-kernel architecture, and the system service invocation device comprises a transceiving module 1101 and a processing module 1102. Figure 11 Figure 11 When the transceiving module 1101 obtains a first invocation request from a first thread, the processing module 1102 is configured to invoke an execution entity to handle the first invocation request by establishing a connection with the execution entity of the first system service, wherein the first invocation request is used to request to invoke the first system service.

[0166] When the transceiving module 1101 obtains a first invocation request from a first thread, the processing module 1102 is configured to invoke an execution entity to handle the first invocation request by establishing a connection with the execution entity of the first system service, wherein the first invocation request is used to request to invoke the first system service.

[0167] ​The transceiving module 1101 is configured to return the processing result to the first thread, and the processing module 1102 is further configured to update the state of the execution entity to a hosting state, where the connection between the execution entity in the hosting state and the kernel is not cleaned up, and the execution entity has a corresponding relationship with the first thread.

[0168] When the transceiving module 1101 obtains the second invocation request from the first thread, the processing module 1102 is further configured to invoke the execution entity to process the second invocation request based on the corresponding relationship and the connection, where the second invocation request is used to request to invoke the first system service.

[0169] In a possible implementation, after the transceiving module 1101 returns the processing result to the first thread, the processing module 1102 is further configured to update the state of the first thread to a corresponding hosting entity state, where the corresponding hosting entity state is used to indicate that the first thread has a corresponding hosted execution entity.

[0170] When the transceiving module 1101 obtains the second invocation request from the first thread, the processing module 1102 is further configured to determine to invoke the execution entity in the hosting state to process the second invocation request based on the state of the first thread.

[0171] In a possible implementation, when the transceiving module 1101 obtains the third invocation request from the first thread, the processing module 1102 is further configured to clean up the connection between the execution entity and update the state of the execution entity to a hibernation waiting state, where the third invocation request is used to request to invoke the second system service, and the execution entity in the hibernation waiting state can be invoked by other threads.

[0172] The processing module 1102 is further configured to invoke the execution entity of the second system service to process the third invocation request by establishing a connection with the execution entity of the second system service, and record the corresponding relationship between the first thread and the execution entity of the second system service.

[0173] In a possible implementation, when the transceiving module 1101 obtains the fourth invocation request from the first thread, if the execution entity is unavailable, the processing module 1102 is further configured to clean up the connection between the execution entity and update the state of the execution entity to a hibernation waiting state, where the fourth invocation request is used to request to invoke the first system service.

[0174] The processing module 1102 is further configured to invoke the other execution entity to process the fourth invocation request by establishing a connection with the other execution entity of the first system service, and record the corresponding relationship between the first thread and the other execution entity.

[0175] In a possible implementation, the first thread corresponds to one hosted execution entity at the same time.

[0176] In a possible implementation, the first system service is in a privileged state or a non-privileged state.

[0177] In a possible implementation, the connection between the execution entity and the kernel is an IPC connection.

[0178] In a possible implementation, the first system service is configured to provide any one or more of the following functions: process management, memory management, a file system, a device driver, and a network service.

[0179] Please refer to Figure 12 , Figure 12 A structural schematic diagram of an electronic device is provided in the present application. As shown in the figure, Figure 12 the electronic device 1200 can specifically be a server, which is not limited herein. Specifically, the electronic device 1200 includes a receiver 1201, a transmitter 1202, a processor 1203 and a memory 1204 (wherein the number of processors 1203 in the electronic device 1200 can be one or more, Figure 12 and the processor 1203 is taken as an example herein), wherein the processor 1203 can include an application processor 12031 and a communication processor 12032. In some embodiments of the present application, the receiver 1201, the transmitter 1202, the processor 1203 and the memory 1204 can be connected through a bus or other means.

[0180] The memory 1204 can include a read-only memory and a random access memory, and provide instructions and data for the processor 1203. A part of the memory 1204 can also include a non-volatile random access memory (NVRAM). The memory 1204 stores processor and operation instructions, executable modules or data structures, or a subset thereof, or an extended set thereof, wherein the operation instructions can include various operation instructions for implementing various operations.

[0181] The processor 1203 controls the operation of the electronic device. In specific applications, various components of the electronic device are coupled together through a bus system, which can include a data bus, a power bus, a control bus and a status signal bus, etc. in addition to the data bus. However, for the sake of clarity, all kinds of buses are referred to as a bus system in the figure.

[0182] The method disclosed in the embodiments of the present application can be applied to the processor 1203 or implemented by the processor 1203. The processor 1203 can be an integrated circuit chip having a signal processing capability. In the implementation process, the steps of the above method can be completed by hardware integrated logic circuits in the processor 1203 or by instructions in the form of software. The processor 1203 described above can be a general processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and can further include an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0183] The processor 1203 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general processor can be a microprocessor or the processor can also be any conventional processor or the like. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as a hardware code processor to execute, or executed by a combination of hardware and software modules in the code processor. The software module can be located in a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register or other mature storage medium in the art. The storage medium is located in the memory 1204, and the processor 1203 reads the information in the memory 1204 and combines the hardware to complete the steps of the above method.

[0184] The receiver 1201 can be used to receive input digital or character information, and to generate signal input related to the relevant settings and function control of the electronic device. The transmitter 1202 can be used to output digital or character information through the first interface; the transmitter 1202 can also be used to send instructions to the disk group through the first interface to modify the data in the disk group; the transmitter 1202 can also include a display device such as a display screen.

[0185] The electronic device provided by the embodiments of the present application can be a chip, which comprises a processing unit, for example, a processor, and a communication unit, for example, an input / output interface, a pin, a circuit or the like. The processing unit can execute computer execution instructions stored in a storage unit, so as to enable the chip in the device to execute the method described in the above embodiments. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache or the like. The storage unit can also be a storage unit outside the chip in the wireless access device, such as a read-only memory (ROM) or other types of static storage device capable of storing static information and instructions, a random access memory (RAM) or the like.

[0186] Reference can be made to Figure 13 , Figure 13 A structural schematic diagram of a computer readable storage medium provided by the present application is provided. The present application also provides a computer readable storage medium, in some embodiments, the above Figure 4 The disclosed method can be implemented as computer program instructions encoded in a computer readable storage medium in a machine readable format or encoded in other non-transitory media or articles.

[0187] Figure 13 A conceptual partial view of an example computer readable storage medium arranged in accordance with at least some embodiments shown herein is schematically depicted, the example computer readable storage medium including a computer program for executing a computer process on a computing device.

[0188] In one embodiment, the computer readable storage medium 1300 is provided using a signal bearing medium 1301. The signal bearing medium 1301 can include one or more program instructions 1302, which when executed by one or more processors, can provide the functionality or some of the functionality described above with respect to Figure 4 the above described functionality or partial functionality.

[0189] In some examples, the signal bearing medium 1301 can include a computer readable medium 1303, such as but not limited to, a hard disk drive, a compact disk (CD), a digital video disc (DVD), a digital tape, memory, ROM or RAM, etc.

[0190] In some embodiments, the signal-bearing medium 1301 may include a computer-recordable medium 1304, such as, but not limited to, a memory, a read / write (R / W) CD, a R / W DVD, etc. In some embodiments, the signal-bearing medium 1301 may include a communication medium 1305, such as, but not limited to, digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.). Therefore, for example, the signal-bearing medium 1301 may be transmitted by a wireless communication medium 1305 (e.g., a wireless communication medium conforming to the IEEE 802.X standard or other transmission protocols).

[0191] One or more program instructions 1302 may be, for example, computer-executable instructions or logical implementation instructions. In some examples, the computing device may be configured to provide various operations, functions, or actions in response to one or more program instructions 1302 conveyed to the computing device via a computer-readable medium 1303, a computer-recordable medium 1304, and / or a communication medium 1305.

[0192] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the accompanying drawings of the device embodiments provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0193] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods of the various embodiments of this application.

[0194] In the above-described embodiments, all or some of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, the embodiments can be implemented in the form of a computer program product.

[0195] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can store or be integrated into a training device, data center, etc. data storage device including one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

Claims

1. A method of invoking a system service, characterized by, The method is applied to a kernel under a micro-kernel architecture, and the method comprises: when a first invocation request from a first thread is obtained, invoking an execution entity of a first system service to process the first invocation request by establishing a connection with the execution entity, wherein the first invocation request is used to request invocation of the first system service; when a processing result is returned by the execution entity, returning the processing result to the first thread and updating a state of the execution entity to a managed state, wherein the connection between the execution entity in the managed state and the kernel is not cleaned up, and the execution entity has a corresponding relationship with the first thread; when a second invocation request from the first thread is obtained, invoking the execution entity to process the second invocation request based on the corresponding relationship and the connection, wherein the second invocation request is used to request invocation of the first system service.

2. The method of claim 1, wherein, After the processing result is returned to the first thread, the method further comprises: updating a state of the first thread to a corresponding managed entity state, wherein the corresponding managed entity state is used to indicate that the first thread has a corresponding managed execution entity; when a second invocation request from the first thread is obtained, determining to invoke the execution entity in the managed state to process the second invocation request based on the state of the first thread.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: when a third invocation request from the first thread is obtained, cleaning up the connection with the execution entity and updating a state of the execution entity to a hibernation waiting state, wherein the third invocation request is used to request invocation of a second system service, and the execution entity in the hibernation waiting state can be invoked by other threads; invoking an execution entity of the second system service to process the third invocation request by establishing a connection with the execution entity of the second system service, and recording a corresponding relationship between the first thread and the execution entity of the second system service.

4. The method according to claim 1 or 2, characterized in that, The method further comprises: when a fourth invocation request from the first thread is obtained, if the execution entity is unavailable, cleaning up the connection with the execution entity and updating a state of the execution entity to a hibernation waiting state, wherein the fourth invocation request is used to request invocation of the first system service; invoking another execution entity of the first system service to process the fourth invocation request by establishing a connection with the other execution entity, and recording a corresponding relationship between the first thread and the other execution entity.

5. The method according to any one of claims 1 to 4, characterized in that, The first thread corresponds to one managed execution entity at the same time.

6. The method according to any one of claims 1 to 5, characterized in that, The first system service is in a privileged state or a non-privileged state.

7. The method according to any one of claims 1 to 6, characterized in that, The connection between the execution entity and the kernel is an inter-process communication (IPC) connection.

8. The method according to any one of claims 1 to 7, characterized in that, The first system service is used to provide any one or more of the following functions: process management, memory management, a file system, a device driver, and a network service.

9. A system service call apparatus, characterized by comprising: The apparatus is applied to a kernel under a micro-kernel architecture, and the apparatus comprises a transceiving module and a processing module. The processing module is configured to invoke the execution entity to process the first invocation request by establishing a connection with an execution entity of the first system service when the transceiving module obtains the first invocation request from the first thread, wherein the first invocation request is configured to request invocation of the first system service. The transceiving module is configured to return the processing result to the first thread when the execution entity returns the processing result, and the processing module is further configured to update a state of the execution entity to a hosting state, wherein the connection between the execution entity in the hosting state and the kernel is not cleaned up, and the execution entity has a correspondence relationship with the first thread. The processing module is further configured to invoke the execution entity to process the second invocation request based on the correspondence relationship and the connection when the transceiving module obtains the second invocation request from the first thread, wherein the second invocation request is configured to request invocation of the first system service.

10. The apparatus of claim 9, wherein, The processing module is further configured to update a state of the first thread to a corresponding hosting entity state after the transceiving module returns the processing result to the first thread, wherein the corresponding hosting entity state is configured to indicate that the first thread has a corresponding hosted execution entity. The processing module is further configured to determine to invoke the execution entity in the hosting state to process the second invocation request based on the state of the first thread when the transceiving module obtains the second invocation request from the first thread.

11. The apparatus of claim 9 or 10, wherein The processing module is further configured to clean up the connection with the execution entity and update a state of the execution entity to a hibernation waiting state when the transceiving module obtains a third invocation request from the first thread, wherein the third invocation request is configured to request invocation of a second system service, and the execution entity in the hibernation waiting state can be invoked by other threads. The processing module is further configured to invoke an execution entity of the second system service to process the third invocation request by establishing a connection with the execution entity of the second system service, and record a correspondence relationship between the first thread and the execution entity of the second system service.

12. The apparatus of claim 9 or 10, wherein The processing module is further configured to clean up the connection with the execution entity and update a state of the execution entity to a hibernation waiting state when the transceiving module obtains a fourth invocation request from the first thread if the execution entity is unavailable, wherein the fourth invocation request is configured to request invocation of the first system service. The processing module is further configured to invoke another execution entity of the first system service to process the fourth invocation request by establishing a connection with the other execution entity, and record a correspondence relationship between the first thread and the other execution entity.

13. The apparatus of any of claims 9-12, wherein, The first thread corresponds to one hosted execution entity at the same time.

14. The apparatus of any of claims 9-13, wherein, The first system service is in a privileged state or a non-privileged state.

15. The apparatus of any of claims 9-14, wherein, The connection between the execution entity and the kernel is an IPC connection.

16. The apparatus of any one of claims 9-15, wherein, The first system service is configured to provide any one or more of the following functions: process management, memory management, file system, device driver, and network service.

17. An apparatus for calling a system service, characterized by comprising: An apparatus comprising a memory storing code and a processor configured to execute the code, the code, when executed, causing the apparatus to perform the method of any one of claims 1 to 8.

18. A computer storage medium, comprising, A computer storage medium storing instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8.

19. A computer program product, characterised in that, A computer program product storing instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8.

Images