System service calling method and related apparatus

Abstract

Provided in the present application is a system service calling method, which is applied to a kernel in a microkernel architecture. In the system service calling method, when obtaining from a thread a request for calling a certain system service for the first time, the kernel establishes a connection with an execution entity of the system service and calls the execution entity to process the request; and, after the execution entity completes processing of the request, the kernel will not clean the connection with the execution entity but instead update the state of the execution entity to a hosted state, so as to keep a corresponding relationship between the thread and the execution entity. In this way, when the thread calls the system service again next time, on the basis of the kept corresponding relationship and the connection with the execution entity, the kernel can quickly call the execution entity in the hosted state to process the request from the thread, thus improving the efficiency of the thread calling the system service.

Description

Method for calling system service and related device

[0001] The present application claims priority to the Chinese patent application No. 202410801763.X, filed on June 19, 2024, and entitled "Method for calling system service and related device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

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

[0003] Micro kernel architecture and monolithic kernel architecture are two main forms of kernel architecture of operating system. Compared with monolithic kernel architecture which uses a kernel to provide all operating system functions, micro kernel architecture follows the principle of minimization, 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.

[0004] 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.

[0005] 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 service through the kernel, resulting in low efficiency of the application program calling the system service. SUMMARY

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

[0007] The first aspect of the present application provides a method for calling system service, which is applied to a kernel under a micro kernel architecture. Specifically, the method for calling system service 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 execution entity of a first system service, and records the correspondence 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.

[0008] When the execution entity completes processing the first call request and returns the result, the kernel returns the result to the first thread and updates the execution entity's state to managed. The connection between the execution entity and the kernel in the managed state is not cleaned up. That is, the kernel does not clean up the connection between itself and the execution entity, nor does it release the execution entity to the resource pool; instead, it updates the execution entity's state to managed. The connection between the execution entity and the kernel in the managed state is not cleaned up but is maintained indefinitely. While the execution entity is in the managed state, the kernel will manage the execution entity and maintain the correspondence between the first thread and the execution entity, ensuring that the execution entity can only be called by the first thread and cannot be called by other threads.

[0009] Secondly, upon receiving a second call request from the first thread, the kernel processes the second call request by invoking the execution entity based on the correspondence and connection. This second call request requests to invoke the first system service. That is, the kernel can determine, based on the maintained correspondence between the first thread and execution entities, that the first thread currently corresponds to an execution entity of the first system service in a managed state. In this way, the kernel does not need to search for other execution entities of the first system service to process the second call request; instead, it directly invokes the execution entity to process the second call request based on the connection between the kernel and the managed execution entity. This allows the kernel to invoke the execution entity in a near-direct invocation manner, rather than through inter-process communication (IPC).

[0010] In this scheme, when the kernel receives a thread's first request to call a system service, the kernel establishes a connection with the execution entity of that system service and invokes the execution entity to handle the request. After the execution entity completes processing the request, the kernel does not clean up the connection with the execution entity but updates the execution entity's state to managed state, thus preserving the correspondence between the thread and the execution entity. In this way, when the thread subsequently calls the system service again, the kernel can quickly invoke the execution entity in managed state to handle the thread's request based on the preserved correspondence and the connection with the execution entity. This allows the kernel to invoke the execution entity in a near-direct invocation manner, rather than through inter-process communication (IPC), improving the efficiency of thread calls to system services.

[0011] In one possible implementation, after returning the processing result to the first thread, the kernel can update the first thread's state to a state with a corresponding managed entity. This managed entity state indicates that the first thread has a corresponding managed execution entity. Thus, when a second call request is received from the first thread, based on the first thread's state (i.e., the managed entity state), the kernel can quickly determine that a managed execution entity needs to be invoked to handle the second call request, without needing to find or create another execution entity to handle the second call request.

[0012] In this solution, by updating the state of the first thread to the state of having a managed entity, the kernel can quickly determine whether the first thread currently has a managed execution entity when it receives a call request from the first thread. This allows the kernel to determine whether to directly call the managed execution entity or search for or create another execution entity, thereby improving the efficiency of system service calls.

[0013] In one possible implementation, when a third call request is received from the first thread, the kernel cleans up the connection between the kernel and the execution entity and updates the execution entity's state to a dormant waiting state. The third call request is used to request a call to a second system service, and the execution entity in the dormant waiting state can be called by other threads.

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

[0015] In this scheme, when a thread corresponds to an execution entity of a certain system service that is in a managed state, when the thread requests to call another system service, the kernel triggers the cleanup of the connection with the execution entity in the managed state and releases the execution entity. Based on the new call request, it establishes a connection with the execution entity of another system service to call the execution entity of the other system service to handle the thread's call request, ensuring the normal call of the system service and avoiding the waste of resources caused by too many execution entities in the managed state corresponding to the same thread.

[0016] In one possible implementation, when a fourth call request is received from the first thread, if the execution entity is unavailable, the kernel cleans up the connection with the execution entity and updates the execution entity's state to a dormant waiting state. The fourth call request is used to request a call to the first system service.

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

[0018] In other words, if the execution entity of a system service in a managed state becomes unavailable, the kernel can release this managed execution entity, establish a connection with other execution entities under the same system service, and call other execution entities to handle the thread's call request, so as to ensure that the call request sent by the thread can be processed normally and the normal call of the system service can be guaranteed.

[0019] When the execution entity of the first system service is unavailable, since the overhead of notifying the execution entity that it cannot continue execution on the current processor is close to the overhead of calling a new execution entity, this solution releases the execution entity in the managed state and calls a new execution entity based on the call request to handle the issue, thereby minimizing changes to the existing technology and improving the feasibility and compatibility of this solution.

[0020] In one possible implementation, the first thread corresponds to one managed execution entity at any given time. That is, the kernel will only manage one execution entity for the first thread at any given time, and will not manage multiple different execution entities for the first thread.

[0021] In this solution, by setting the kernel to host only one execution entity for the same thread at any given time, it is possible to ensure high system service call efficiency while minimizing system complexity and the processing resources occupied by the system.

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

[0023] In one possible implementation, the connection between the execution entity and the kernel is an inter-process communication (IPC) connection.

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

[0025] The second aspect of this application provides a system service invocation device, which is applied to a kernel implementing a microkernel architecture. The system service invocation device includes: a transceiver module and a processing module.

[0026] When the sending and receiving module receives the first call request from the first thread, the processing module is used to establish a connection with the execution entity of the first system service to call the execution entity to process the first call request, and to record the correspondence between the first thread and the execution entity, wherein the first call request is used to request to call the first system service;

[0027] When the execution entity returns the processing result, the transceiver module is used to return the processing result to the first thread, and the processing module is also used to update the state of the execution entity to the managed state. The connection between the execution entity in the managed state and the kernel will not be cleaned up.

[0028] When the sending and receiving module receives a second call request from the first thread, the processing module is also used to process the second call request based on the correspondence and connection call execution entity. The second call request is used to request to call the first system service.

[0029] In one possible implementation, after the sending and receiving module returns the processing result to the first thread, the processing module is also used to update the state of the first thread to the state of having a corresponding managed entity. The state of having a corresponding managed entity is used to indicate that the first thread has a corresponding managed execution entity.

[0030] When the sending and receiving module receives a second call request from the first thread, the processing module is also used to determine, based on the state of the first thread, the execution entity in the managed state to handle the second call request.

[0031] In one possible implementation, when the transceiver module receives a third call request from the first thread, the processing module is also used to clean up the connection between the execution entity and update the execution entity's state to a dormant waiting state. The third call request is used to request to call the second system service, and the execution entity in the dormant waiting state can be called by other threads.

[0032] The processing module is also used to call 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 to record the correspondence between the first thread and the execution entity of the second system service.

[0033] In one possible implementation, when the sending and receiving module receives the fourth call request from the first thread, if the execution entity is unavailable, the processing module is also used to clean up the connection with the execution entity and update the execution entity's state to a dormant waiting state, wherein the fourth call request is used to request to call the first system service;

[0034] The processing module is also used to call other execution entities to process the fourth call request by establishing a connection with other execution entities of the first system service, and to record the correspondence between the first thread and other execution entities.

[0035] In one possible implementation, the first thread corresponds to a managed execution entity at any given time.

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

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

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

[0039] A third aspect of this application provides a system service invocation apparatus, which may include a processor, a processor coupled to a memory, and the memory storing program instructions. When the program instructions stored in the memory are executed by the processor, the method described in the first aspect or any implementation thereof is implemented. For details regarding the steps of the various possible implementations of the first aspect executed by the processor, please refer to the first aspect; further details will not be repeated here.

[0040] The fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method of any implementation of the first aspect described above.

[0041] The fifth aspect of this application provides a circuit system including a processing circuit configured to perform the method of any implementation of the first aspect described above.

[0042] The sixth aspect of this application provides a computer program product that, when run on a computer, causes the computer to perform any implementation of the first aspect described above.

[0043] A seventh aspect of this application provides a chip system including a processor for supporting a server in implementing the functions involved in any implementation of the first aspect described above, such as processing data and / or information involved in the methods described above. In one possible design, the chip system further includes a memory for storing necessary program instructions and data for the server. This chip system may be composed of chips or may include chips and other discrete devices.

[0044] The beneficial effects of the second to seventh aspects mentioned above can be referred to the introduction of the first aspect above, and will not be repeated here. Attached Figure Description

[0045] Figure 1 is a comparative diagram of application calls to system services under a single kernel architecture and a microkernel architecture in related technologies;

[0046] Figure 2 is a schematic diagram of a system architecture provided in this application;

[0047] Figure 3 is a structural schematic diagram of an execution device 101 provided in this application;

[0048] Figure 4 is a flowchart illustrating a method for invoking a system service provided in this application;

[0049] Figure 5 is a schematic diagram of an application scenario for a system service invocation method provided in this application;

[0050] Figure 6 is a comparative diagram of thread calling system services under a microkernel architecture provided in this application;

[0051] Figure 7 is a schematic diagram of a thread calling a system service according to this application;

[0052] Figure 8 is a schematic diagram of a thread calling system services under different circumstances according to this application;

[0053] Figure 9 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;

[0054] Figure 10 is a schematic diagram illustrating the relationship between a thread, kernel, and execution entity provided in this application;

[0055] Figure 11 is a schematic diagram of the structure of a system service invocation device provided in this application;

[0056] Figure 12 is a schematic diagram of the structure of an electronic device provided in this application;

[0057] Figure 13 is a schematic diagram of the structure of a computer-readable storage medium provided in this application. Detailed Implementation

[0058] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0059] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0060] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0061] For ease of understanding, some technical terms involved in the embodiments of this application will be introduced below.

[0062] (1) Microkernel architecture

[0063] A microkernel architecture is a type of operating system kernel architecture. A typical characteristic of a microkernel architecture is that the kernel retains only the most basic and core operating system functions (such as interrupt management, exception management, memory mapping management, and inter-process communication), while other functions (such as process management, memory management, and file systems) are implemented as system services.

[0064] (2) Monolithic kernel architecture

[0065] Monolithic kernel architecture is a type of operating system kernel architecture. Compared to microkernel architecture, the typical characteristic of monolithic kernel architecture is that all services of the operating system (such as process management, memory management, file system, device drivers, network protocols, etc.) run in the same space and the same privileged state.

[0066] (3) System Services

[0067] A system service is a program, routine, or process that performs a specified system function to enable other programs to access that function. In a microkernel system, a system service typically provides a specific function (such as process management, memory management, file system, device drivers, network protocols, etc.), and system services usually reside in a different privileged state than the microkernel itself.

[0068] (4) Execution Entity

[0069] An execution entity is an object within a system service that provides services for a single user call. Generally, an execution entity includes a user stack located within the system service and control information located in the kernel.

[0070] (5) Privileged status

[0071] Privileged mode refers to the runtime state of the operating system's management program, which has a higher level of privilege. Specifically, if an application is running in privileged mode, the application can access the computer's task resources, meaning that the application's resource access permissions are unrestricted.

[0072] (6) Non-privileged state

[0073] Non-privileged mode, also known as user mode, refers to the runtime state of an application, which has a lower privilege level. Specifically, if an application runs in non-privileged mode, the resources it can access will be restricted.

[0074] (7) Kernel

[0075] The kernel is the most fundamental part of an operating system; essentially, it's a piece of software that provides secure access to computer hardware for numerous applications. The kernel provides the most basic functions of the operating system and is the foundation for its operation.

[0076] (8) Inter-process Communication (IPC)

[0077] IPC refers to the transmission or exchange of information between different processes.

[0078] (9) Process

[0079] A process is a single execution of a program on a specific set of data in a computer. It is the basic unit for resource allocation in a system and the foundation of the operating system architecture. In early process-oriented computer architectures, a process was the fundamental execution entity of a program; in contemporary thread-oriented computer architectures, a process is a container for threads. A program is a description of instructions, data, and their organization; a process is the entity within a program.

[0080] (10) Thread

[0081] A thread is the smallest unit of computation that an operating system can schedule. Threads are contained within processes and are the actual units of operation within a process. A thread refers to a single, sequential flow of control within a process; multiple threads can run concurrently within a process, each executing different tasks in parallel.

[0082] (11) System calls

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

[0084] The applicant's research found that, compared to a monolithic kernel architecture, a microkernel architecture often incurs more performance overhead when applications call system services, resulting in lower efficiency for applications calling system services.

[0085] For example, please refer to Figure 1, which is a comparative diagram of application calls to system services under a monolithic kernel architecture and a microkernel architecture in related technologies. As shown in Figure 1, under a monolithic kernel architecture, during the execution of an application, after the application's corresponding thread enters the kernel through a system call (syscall) or exception, since all kernel components reside in the same system space and the same privileged state, the kernel can obtain various system services through function calls. However, in a microkernel system, after the application's corresponding thread enters the kernel through a syscall or exception, due to the isolation between the kernel and system services, it needs to obtain system services through IPC. Furthermore, after the system service completes its execution, it also needs to return to the thread through IPC. Therefore, compared to a monolithic kernel architecture, a thread calls a system service at least twice more, resulting in the microkernel architecture needing to perform more work than the monolithic kernel architecture for each identical operating system function.

[0086] Compared to function calls, IPC often incurs greater overhead. In a microkernel architecture, IPC mainly includes necessary processes such as connection establishment and context switching. Connection establishment involves several steps: a) authentication, determining whether the user has the right to call; b) finding or creating the execution entity of the system service; c) recording the call chain, as the kernel needs to record the entire call process, otherwise it cannot return; d) synchronizing some connection information to the system service. Context switching includes at least two steps: e) general-purpose register switching; taking the arm64 architecture as an example, one IPC operation requires saving and restoring 31 general-purpose registers; f) privilege level and address space switching.

[0087] In general, because most system services are isolated from the kernel in a microkernel architecture, application threads often need to perform multiple IPC-related steps when calling system services through the kernel, resulting in low efficiency for application threads to call system services.

[0088] In view of this, this application provides a method for invoking system services. When the kernel receives a thread's first request to invoke a system service, the kernel establishes a connection with the execution entity of that system service and invokes the execution entity to handle the request. After the execution entity completes the request processing, the kernel does not clean up the connection with the execution entity but updates the execution entity's state to a managed state, thereby preserving the correspondence between the thread and the execution entity. Thus, when the thread subsequently invokes the system service again, the kernel can quickly invoke the execution entity in the managed state to handle the thread's request based on the preserved correspondence and the connection with the execution entity, thereby improving the efficiency of thread invoking system services. Furthermore, the method provided in this application is applicable to microkernel architectures, maintaining the advantages of microkernel architectures and possessing versatility and good compatibility.

[0089] Please refer to Figure 2, which is a schematic diagram of a system architecture provided in this application. As shown in Figure 2, in the system architecture, the execution device 101 can be, for example, a physical host or a physical server. Furthermore, the execution device 101 is communicatively connected to the data storage system 102 to obtain the program code stored in the data storage system 102, thereby implementing the system service invocation method provided in this application. The data storage system 102 can 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 can 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 specifically for storing program code.

[0090] During operation, the execution device 101 can obtain program code and related data required for calling system services from the data storage system 102, and based on the system service calling method provided in this application, it can improve the efficiency of thread calling system services on the execution device 101.

[0091] Please refer to Figure 3, which is a schematic diagram of the structure of an execution device 101 provided in this application. As shown in Figure 3, the execution device 101 used in the system service invocation method provided in this application includes a processor 103, which is coupled to 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 drives a display 109, which is coupled to the system bus 105. The system bus 105 is coupled to an input / output (I / O) bus via a bus bridge 111. An I / O interface 115 is coupled to 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 device 121 (e.g., a hard disk, floppy disk, optical disk, or USB flash 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. Optionally, the interface connected to the I / O interface 115 can be a USB interface.

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

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

[0094] Hard disk drive interface 131 is coupled to system bus 105. Hardware driver interface is connected to hard disk drive 133. Internal memory 135 is coupled to system bus 105. Data running in internal memory 135 may include operating system (OS) 137, applications 143, and schedules of execution device 101.

[0095] An operating system consists of the Shell 139 and the kernel 141. The Shell 139 is an interface between the user and the operating system kernel. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system: waiting for user input, interpreting user input for the operating system, and processing various operating system outputs.

[0096] Kernel 141 consists of the parts of the operating system used to manage memory, files, peripherals, and system resources. Kernel 141 interacts directly with the hardware. The operating system kernel typically runs processes and provides inter-process communication, CPU time-slice management, interrupts, memory management, I / O management, and so on.

[0097] Please refer to Figure 4, which is a flowchart illustrating a system service invocation method provided in this application. As shown in Figure 4, the system service invocation method is applied to a kernel under a microkernel architecture, specifically including the following steps 401-403.

[0098] Step 401: When a first call request is received from the first thread, the execution entity is invoked to process the first call request by establishing a connection with the execution entity of the first system service, wherein the first call request is used to request to invoke the first system service.

[0099] In this application, the first thread can specifically be a thread corresponding to a user application running on the execution device, and this application does not limit the specific form of the first thread. During the execution of the first thread, when the first thread needs to call a system service, the first thread can send a first call request to the kernel through syscall or exception, which is used to request the invocation of the first system service.

[0100] After the kernel receives the first call request, it checks the resource pool to see if there is an existing, idle execution entity for the first system service. If such an entity exists, the kernel establishes a connection with it and invokes it to handle the first call request. If no such entity exists, the kernel creates one, establishes a connection, and invokes it to handle the request. The resource pool can store created execution entities that have not yet been invoked by other threads. For any system service, the kernel can pre-create one or more execution entities and store them in the resource pool, so that when the system service is called later, the kernel can retrieve the created execution entities from the resource pool to handle the corresponding call request.

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

[0102] Specifically, the kernel can establish a connection with the execution entity of the first system service and invoke the execution entity to handle the first call request via IPC. The process of the kernel establishing a connection with the execution entity and invoking the execution entity via IPC can be referred to the above introduction, and will not be repeated here.

[0103] In addition, when the kernel calls the execution entity of the first system service to handle the first call 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.

[0104] Optionally, in this application, the first system service may be used to provide one or more of the following functions: process management, memory management, file system, device driver, and network services. In general, the first system service can be a system service that provides any function other than the basic functions, and this application does not specifically limit it.

[0105] 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 the managed state. The connection between the execution entity and the kernel in the managed state will not be cleaned up, and the execution entity and the first thread have a corresponding relationship.

[0106] After the execution entity of the first system processes the first call request, it can return the processing result to the kernel. After receiving the result returned by the execution entity, the kernel will then return the result to the first thread to complete the entire process of the first thread calling the service of the first system.

[0107] It is worth noting that in this application, after the kernel returns the processing result to the first thread, it does not clean up the connection between the kernel and the execution entity, nor does it release the execution entity to the resource pool. Instead, it updates the execution entity's state to managed. The connection between the execution entity and the kernel in the managed state is not cleaned up but is maintained indefinitely. While the execution entity is in the managed state, the kernel will manage the execution entity and maintain the connection with it, thus ensuring that the execution entity can only be invoked by the first thread and cannot be invoked by other threads.

[0108] In addition, the kernel retains the correspondence between the first thread and the execution entity recorded when the execution entity handles the first call request, so as to indicate that the thread corresponding to the execution entity currently in a managed state is the first thread.

[0109] Step 403: When a second call request is received from the first thread, the second call request is processed based on the correspondence and the connection call execution entity. The second call request is used to request to call the first system service.

[0110] In this application, when the first thread needs to continue calling the first system service, it sends a second call request to the kernel to request the call to the first system service. After the kernel updates the state of the execution entity of the first system service to a managed state, upon receiving the second call request, the kernel can determine, based on the retained correspondence between the first thread and execution entities, that the first thread currently corresponds to an execution entity of the first system service in a managed state. Thus, the kernel does not need to search for other execution entities of the first system service to handle the second call request; instead, it directly calls the execution entity to handle the second call request based on the connection between the kernel and the execution entity in the managed state. This allows the kernel to call the execution entity in a near-direct call manner, rather than using an IPC method.

[0111] In other words, after the kernel updates the execution entity of a system service to the managed 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 managed state to handle the thread's call request, without having to establish a connection with the execution entity based on the conventional IPC method. This eliminates multiple steps in the execution entity call process and improves the calling efficiency of system services.

[0112] Optionally, in step 402 above, after returning the processing result to the first thread, the kernel can also update the state of the first thread to the state of having a corresponding managed entity. The state of having a corresponding managed entity indicates that the first thread has a corresponding managed execution entity. That is, the states of both the first thread and the execution entity corresponding to the first thread have been updated. The state of the first thread is the state of having a corresponding managed entity, while the state of the execution entity corresponding to the first thread is the managed state.

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

[0114] In other words, by updating the state of the first thread to the state of having a managed entity, the kernel can quickly determine whether the first thread currently has a managed execution entity when it receives a call request from the first thread. This allows it to determine whether to directly call the managed execution entity or search for or create another execution entity, thereby improving the efficiency of system service calls.

[0115] Optionally, the aforementioned first system service can be in either a privileged or non-privileged state. It should be noted that in current processor instruction set architectures, switching between non-privileged and privileged states often involves processor pipeline flushing, resulting in additional overhead. Specifically, switching between non-privileged and privileged states incurs address space switching overhead. Since in current processor instruction set architectures, a processor can only run one privileged address space and one non-privileged address space simultaneously, if a system service is in a non-privileged state, the processor needs to replace the address space of the thread calling the service with the address space of the system service before execution can continue. Conversely, if a system service is in a privileged state, the processor does not need to replace the address space when the kernel calls it, further saving on privilege level and address space switching overhead (i.e., the overhead f mentioned above).

[0116] Since each processor has a corresponding register to record which address space the currently running thread belongs to, the address space pointed to by the processor's corresponding register is called the processor's current running address space. That is, the privileged or non-privileged address space that the processor runs in refers to the address space where the currently running thread or execution entity runs.

[0117] The above describes how, when the execution entity corresponding to the first thread is in a managed state, the kernel directly invokes that execution entity to handle the call request sent by the first thread when the first thread calls the same system service a second time. In some cases, the execution entity corresponding to the first thread may not be able to handle subsequent call requests sent by the first thread. In this case, the connection between the kernel and the execution entity can be cleared and the execution entity released to the resource pool, thus changing the execution entity from the managed state corresponding to the first thread to a dormant waiting state.

[0118] In a possible example, after the kernel updates the state of the execution entity of the first system service to the managed state, upon receiving a third call request from the first thread to invoke the second system service, the kernel cleans up the connection with the aforementioned execution entity and updates the execution entity's state to a dormant waiting state. The execution entity in the dormant waiting state can be invoked by other threads. That is, the kernel effectively cleans up the IPC connection with the execution entity and releases the execution entity into the resource pool, causing the execution entity's state to change from the managed state corresponding only to the first thread to the dormant waiting state.

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

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

[0121] Similarly, after the execution entity of the second system service finishes processing the third call request and returns the processing result to the kernel, the kernel returns the processing result to the first thread, 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 managed state. In this way, if the first thread continues to request to call the second system service, the kernel can also quickly call the execution entity of the second system service corresponding to the first thread to handle the request from the first thread.

[0122] In this scheme, when a thread corresponds to an execution entity of a certain system service that is in a managed state, when the thread requests to call another system service, the kernel triggers the cleanup of the connection with the execution entity in the managed state and releases the execution entity. Based on the new call request, it establishes a connection with the execution entity of another system service to call the execution entity of the other system service to handle the thread's call request, ensuring the normal call of the system service and avoiding the waste of resources caused by too many execution entities in the managed state corresponding to the same thread.

[0123] In another possible example, after the kernel updates the state of the execution entity of the first system service to the managed state, when it receives a fourth call request from the first thread to invoke the first system service, if the execution entity is unavailable, the kernel will clean up the connection with the execution entity and update the execution entity's state to a dormant waiting state. That is, if the managed execution entity corresponding to the first thread continues to call the same system service, and the kernel itself is unavailable, it will also clean up the connection with the currently managed execution entity and release the execution entity.

[0124] Then, the kernel establishes connections with other execution entities of the first system service to call other execution entities to handle the fourth call request, and records the correspondence between the first thread and other execution entities.

[0125] In other words, if the execution entity of a system service in a managed state becomes unavailable, the kernel can release this managed execution entity, establish a connection with other execution entities under the same system service, and call other execution entities to handle the thread's call request, so as to ensure that the call request sent by the thread can be processed normally and the normal call of the system service can be guaranteed.

[0126] Specifically, 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, thereby causing all other execution entities of the first system service to be unable to continue execution on the current processor. Of course, the unavailability of the execution entity of the first system service can also be due to other reasons, such as execution entity exceptions, etc., and this application does not specifically limit it in this regard.

[0127] When the execution entity of the first system service is unavailable, since the overhead of notifying the execution entity that it cannot continue execution on the current processor is close to the overhead of calling a new execution entity, this solution releases the execution entity in the managed state and calls a new execution entity based on the call request to handle the situation. This minimizes the modification to the existing technology and does not introduce additional overhead, thus improving the feasibility and compatibility of this solution.

[0128] Optionally, in this application, the first thread corresponds to only one managed execution entity at a time. That is, the kernel will only manage one execution entity for the first thread at any given time, and will not manage multiple different execution entities for the first thread. Generally, when the kernel manages only one execution entity for a thread, the efficiency of system service calls can be effectively improved; when the kernel manages multiple execution entities for a thread, compared to the kernel managing only one execution entity, there is no further significant improvement in the efficiency of system service calls. However, compared to the kernel managing only one execution entity for a thread, the kernel managing multiple execution entities for a thread is considerably more complex and requires more processing resources. Therefore, by setting the kernel to manage only one execution entity for the same thread at a time, it is possible to ensure high system service call efficiency while minimizing system complexity and the processing resources occupied by the system.

[0129] Of course, in some embodiments, the kernel may also manage multiple execution entities for the first thread, and these multiple execution entities may be execution entities under different system services. In this way, when the first thread repeatedly calls a system service that has already been called, the kernel can directly call the execution entity in the managed state, thereby improving the efficiency of system service calls in various situations.

[0130] The above describes the method for calling the system services provided in this application. To facilitate understanding, the following will describe in detail the execution process of the method for calling the system services provided in this application with specific examples.

[0131] Please refer to Figure 5, which is a schematic diagram of an application scenario for a system service invocation method provided in this application. As shown in Figure 5, the system service invocation method provided in this application is applied to a microkernel architecture, which includes the following three levels of components: kernel, system services, and user processes. In the microkernel architecture, different applications at the user level manifest as different user processes at runtime (e.g., user process 1 to user process N in Figure 5), and each user process can run one or more threads. The microkernel architecture can include multiple system services, and different system services can be used to provide different system functions, such as memory management, file system, process management, device drivers, and network protocols shown in Figure 5. Furthermore, the same system service can have one or more execution entities, which are responsible for implementing the functions corresponding to the system service.

[0132] Specifically, the entry point for a thread to use any operating system function is through a system call or exception handling. After the thread enters the kernel, the kernel decides whether to handle the requested function itself or dispatch it to the appropriate system service. Similarly, after the system service completes its processing, a dedicated system call is triggered, entering the kernel. The kernel tracks the call relationship between the thread and the system service, allowing it to return the processing result to the thread, enabling it to continue execution.

[0133] Please refer to Figure 6, which is a comparative diagram illustrating thread-to-system service calls under a microkernel architecture provided in this application. As shown in Figure 6, in related technologies, after a thread enters the kernel via syscall or exception, the kernel needs to obtain system services through IPC. Furthermore, after the system service completes its execution, it first returns the processing result to the kernel via syscall or exception, and then the kernel returns the processing result to the thread via IPC.

[0134] In the scheme provided in this application, a thread initiates a request to the kernel to obtain a system service. The kernel still uses IPC to provide the system service to the thread. After the system service completes the processing of the request, before returning to the thread from the system service, the kernel does not release the execution entity or clean up the IPC connection. Instead, it takes over the execution entity of the currently used system service.

[0135] In this way, when a thread calls a system service again, it can first enter the kernel through a syscall or exception. At this time, the kernel can directly call the managed execution entity to handle the call request sent by the thread, without having to obtain the system service through IPC, thus avoiding multiple steps related to IPC.

[0136] This approach involves dynamic optimization on a microkernel architecture, rather than a complete system architecture refactoring. Therefore, it maintains the advantages of a microkernel architecture and offers excellent compatibility. Furthermore, all actions are performed within the kernel and system services, making it transparent to user-side threads (i.e., no adjustments to user-side application code are required). It also avoids modifications that conflict with the semantics of the Portable Operating System Interface (POSIX) specification, thus demonstrating good versatility and feasibility.

[0137] Please refer to Figure 7, which is a schematic diagram of a thread calling a system service according to this application. As shown in Figure 7, under a microkernel architecture, the process of a thread calling a system service includes the following steps 701-706.

[0138] Step 701: The thread initiates its first call to the system service.

[0139] For example, please refer to Figure 8, which is a schematic diagram of a thread calling a system service under different circumstances according to this application. As shown in Figure 8, when a thread initiates a call to a system service for the first time, the thread may first send a call request to the kernel via syscall to request the call to the system service.

[0140] Upon receiving a call request from a thread, the kernel uses IPC to invoke the execution entity of a system service to handle the request. Specifically, the kernel searches for or creates the execution entity of the system service in the resource pool based on the call request, records the call information, and then jumps to the execution entity of the system service to process the call request.

[0141] Since each call request from a thread requires an execution entity of a system service to handle, and this execution entity typically manifests as a user stack along with relevant service call information (such as caller information or the parameters or results of the call), the kernel, upon receiving a call request from a thread, can either search for an execution entity to handle the request, or create a new execution entity if one cannot be found in the resource pool. The user stack refers to a region within the system service process space.

[0142] 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.

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

[0144] As shown in Figure 8, 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 time, the kernel can mark the execution entity of the system service as managed, that is, manage the execution entity of the system service in the kernel, and the kernel returns the processing result to the thread via IPC.

[0145] 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.

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

[0147] In Figure 9, the thread state machine includes three states: active, with a corresponding managed entity, and inactive. When a thread does not call a system service, it is in the inactive state. When a thread sends a call request to the kernel, triggering the call to 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 state with a corresponding managed entity. When the kernel clears the execution entity of the system service managed by the thread, the thread changes from the state with a corresponding managed entity back to the inactive state.

[0148] Similarly, the execution entity state machine of a system service also includes three states: active, managed, and inactive. When the execution entity of a system service is not invoked, it is in the inactive state. When the kernel invokes the execution entity of a system service to handle a request from a thread, the execution entity changes from the inactive state to the active state. When the kernel manages the execution entity of a system service for a thread, the execution entity changes from the active state to the managed state. When the kernel clears the execution entity of a system service managed by a thread, the execution entity changes from the managed state to the inactive state.

[0149] It's important to note that by introducing new states into the state machine, the kernel can quickly determine how to handle a call request received from a thread. For example, upon receiving a call request from a thread, the kernel can examine the thread's state machine. If the current thread's state is "sleeping and waiting," it means this is the thread's first system service call, and the kernel needs to find or create the corresponding system service execution entity to handle the request. If the current thread's state is "has a corresponding managed entity," it means a corresponding execution entity has already been managed for the thread, and the kernel needs to further determine whether the execution entity managed by the thread is available.

[0150] When the kernel manages the execution entity of a system service, it does not release the execution entity of that system service, nor does it clean up the connection between the kernel and the execution entity of that system service, thus preserving the correspondence between threads and the execution entity of that system service recorded by the kernel.

[0151] In this context, for any thread running in the operating system, after the kernel invokes the execution entity of the corresponding system service for the thread, it can assign a corresponding execution entity to the thread, thereby establishing a hosting relationship between the thread and the execution entity. For example, please refer to Figure 10, which is a schematic diagram illustrating the relationship between a thread, the kernel, and the execution entity provided in this application. As shown in Figure 10, the kernel can uniquely host a corresponding system service execution entity for each thread, ensuring that different threads have a corresponding hosted execution entity after invoking a system service.

[0152] In step 703, the thread continues to initiate calls to system services.

[0153] After a thread receives the processing result returned by the kernel, it can continue to initiate calls to system services as needed. This can involve the thread continuing to call the same system service or calling a different system service. In other words, the system service called by the thread can be the same as or different from the previously called system service.

[0154] In step 704, the kernel determines whether the thread-managed execution entity is available.

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

[0156] There are two possible reasons why the thread-managed execution entity is unavailable.

[0157] The first type of reason is an active reason: the system service called by the thread this time is not the same as the system service corresponding to the execution entity managed by the thread. For example, the thread previously called the file system service, so the kernel managed the execution entity of the file system service for the thread; however, the thread is calling the driver system service this time, and the execution entity managed by the kernel for the thread is the execution entity under the file system service, so the execution entity of the file system service managed by the kernel is unavailable.

[0158] The second type of cause is passive: a change in the state of the thread-managed execution entity. For example, the thread-managed execution entity itself may malfunction; or an execution entity running the same system service may already be running on the current processor, causing the unmanaged execution entity to be unable to continue running on the current processor.

[0159] Step 705: If a managed execution entity is available, the kernel uses the managed execution entity to provide services.

[0160] As shown in Figure 8, if the managed execution entity is available, the kernel can quickly call the managed execution entity (similar to a function call) to handle the call request from the thread, without having to call the execution entity again through IPC to handle the call request.

[0161] It should be noted that when the kernel-managed system service execution entity runs in privileged mode, when calling the system service execution entity to handle the call request, there is no need to replace the address space of the thread's process with the address space of the system service on the processor, thus further saving the overhead of address space replacement.

[0162] Step 706: If the managed execution entity is unavailable, the kernel cleans up the managed execution entity and calls a new execution entity via IPC to provide services.

[0163] As shown in Figure 8, if the managed execution entity becomes unavailable, the kernel needs to clean up the managed execution entity (i.e., clear the connection between the kernel and the managed execution entity and release the execution entity to the resource pool). Furthermore, the kernel needs to use IPC to call a new execution entity to handle the call requests from the threads.

[0164] It should be noted that after the kernel calls an IPC to invoke a new execution entity to complete the call request from the thread, the kernel will continue to manage a new execution entity for the thread, thereby ensuring that the thread has a corresponding managed execution entity after each call to a system service.

[0165] The method provided in this application has been described in detail above. Next, the device provided in this application for performing the above method will be described.

[0166] Please refer to Figure 11, which is a schematic diagram of the structure of a system service invocation device provided in this application. As shown in Figure 11, the system service invocation device is applied to implement a kernel under a microkernel architecture. The system service invocation device includes: a transceiver module 1101 and a processing module 1102;

[0167] When the transceiver module 1101 receives the first call request from the first thread, the processing module 1102 is used to call the execution entity to process the first call request by establishing a connection with the execution entity of the first system service, wherein the first call request is used to request to call the first system service.

[0168] When the execution entity returns the processing result, the transceiver module 1101 is used to return the processing result to the first thread, and the processing module 1102 is also used to update the state of the execution entity to the managed state. The connection between the execution entity and the kernel in the managed state will not be cleaned up, and the execution entity and the first thread have a corresponding relationship.

[0169] When the transceiver module 1101 receives a second call request from the first thread, the processing module 1102 is also used to process the second call request based on the correspondence and connection call execution entity. The second call request is used to request to call the first system service.

[0170] In one possible implementation, after the transceiver module 1101 returns the processing result to the first thread, the processing module 1102 is further used to update the state of the first thread to the state of having a corresponding managed entity. The state of having a corresponding managed entity is used to indicate that the first thread has a corresponding managed execution entity.

[0171] When the transceiver module 1101 receives a second call request from the first thread, the processing module 1102 is also used to determine, based on the state of the first thread, the execution entity in the managed state to process the second call request.

[0172] In one possible implementation, when the transceiver module 1101 receives a third call request from the first thread, the processing module 1102 is also used to clean up the connection between the execution entity and update the state of the execution entity to a dormant waiting state. The third call request is used to request to call the second system service, and the execution entity in the dormant waiting state can be called by other threads.

[0173] The processing module 1102 is also used to call 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 to record the correspondence between the first thread and the execution entity of the second system service.

[0174] In one possible implementation, when the transceiver module 1101 receives the fourth call request from the first thread, if the execution entity is unavailable, the processing module 1102 is also used to clean up the connection with the execution entity and update the state of the execution entity to a dormant waiting state, wherein the fourth call request is used to request to call the first system service.

[0175] The processing module 1102 is also used to call other execution entities to process the fourth call request by establishing a connection with other execution entities of the first system service, and to record the correspondence between the first thread and other execution entities.

[0176] In one possible implementation, the first thread corresponds to a managed execution entity at any given time.

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

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

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

[0180] Please refer to Figure 12, which is a schematic diagram of the structure of an electronic device provided in this application. As shown in Figure 12, the electronic device 1200 can specifically be represented as a server, but this is not limited here. Specifically, the electronic device 1200 includes: a receiver 1201, a transmitter 1202, a processor 1203, and a memory 1204 (wherein the electronic device 1200 may have one or more processors 1203, and Figure 12 shows one processor as an example), wherein the processor 1203 may include an application processor 12031 and a communication processor 12032. In some embodiments of this application, the receiver 1201, transmitter 1202, processor 1203, and memory 1204 may be connected via a bus or other means.

[0181] Memory 1204 may include read-only memory and random access memory, and provides instructions and data to processor 1203. A portion of memory 1204 may also include non-volatile random access memory (NVRAM). Memory 1204 stores processor and operation instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operation instructions may include various operation instructions for implementing various operations.

[0182] Processor 1203 controls the operation of electronic devices. In specific applications, the various components of electronic devices are coupled together through a bus system, which may include not only data buses but also power buses, control buses, and status signal buses. However, for clarity, all buses in the diagram are referred to as a bus system.

[0183] The methods disclosed in the embodiments of this application described above can be applied to processor 1203, or implemented by processor 1203. Processor 1203 can be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of processor 1203 or by instructions in the form of software. The processor 1203 described above can be a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and may further include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0184] The processor 1203 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 1204. The processor 1203 reads information from memory 1204 and, in conjunction with its hardware, completes the steps of the above methods.

[0185] Receiver 1201 can be used to receive input digital or character information, and to generate signal inputs related to the settings and function control of electronic devices. Transmitter 1202 can be used to output digital or character information through the first interface; 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; transmitter 1202 may also include a display device such as a display screen.

[0186] The electronic device provided in this application embodiment can specifically be a chip, which includes a processing unit and a communication unit. The processing unit can be, for example, a processor, and the communication unit can be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in the storage unit to cause the chip in the execution device to execute the methods described in the above embodiments. Optionally, the storage unit can be a storage unit within the chip, such as a register or cache. The storage unit can also be a storage unit located outside the chip in the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, such as random access memory (RAM).

[0187] Referring to Figure 13, which is a schematic diagram of the structure of a computer-readable storage medium provided in this application. This application also provides a computer-readable storage medium in which, in some embodiments, the method disclosed in Figure 4 above can be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or on other non-transitory media or articles of art.

[0188] Figure 13 schematically illustrates a conceptual partial view of an example computer-readable storage medium arranged according to at least some of the embodiments shown herein, the example computer-readable storage medium including a computer program for executing computer processes on a computing device.

[0189] In one embodiment, the computer-readable storage medium 1300 is provided using a signal bearer medium 1301. The signal bearer medium 1301 may include one or more program instructions 1302, which, when executed by one or more processors, can provide the functions or parts thereof described above with reference to FIG4.

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

[0191] 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).

[0192] 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.

[0193] 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.

[0194] 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.

[0195] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0196] A 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 flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions may be transferred from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for invoking a system service, characterized in that, The method is applied to kernels under a microkernel architecture, and the method includes: When a first call request is received from the first thread, the execution entity of the first system service is invoked to process the first call request by establishing a connection with the execution entity of the first system service, wherein the first call request is used to request to invoke the first system service; 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 managed state. The connection between the execution entity and the kernel in the managed state is not cleaned up, and the execution entity has a corresponding relationship with the first thread. When a second call request is received from the first thread, the execution entity is invoked based on the correspondence and the connection to process the second call request, which is used to request the invocation of the first system service.

2. The method according to claim 1, characterized in that, After returning the processing result to the first thread, the method further includes: The state of the first thread is updated to a state with a corresponding managed entity, wherein the state with a corresponding managed entity is used to indicate that the first thread has a corresponding managed execution entity; Upon receiving a second call request from the first thread, based on the state of the first thread, it is determined that the execution entity in a managed state should be invoked to handle the second call request.

3. The method according to claim 1 or 2, characterized in that, The method further includes: When a third call request is received from the first thread, the connection between the execution entity is cleared and the state of the execution entity is updated to a dormant waiting state. The third call request is used to request a call to the second system service. The execution entity in the dormant waiting state can be called by other threads. The third call request is processed by invoking the execution entity of the second system service through a connection established with the execution entity of the second system service, and the correspondence between the first thread and the execution entity of the second system service is recorded.

4. The method according to claim 1 or 2, characterized in that, The method further includes: When a fourth call request is received from the first thread, if the execution entity is unavailable, the connection with the execution entity is cleared and the state of the execution entity is updated to a dormant waiting state, wherein the fourth call request is used to request to call the first system service; The first thread is invoked to process the fourth invocation request by establishing a connection with other execution entities of the first system service, and the correspondence between the first thread and the other execution entities is recorded.

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

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

7. The method according to any one of claims 1-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-7, characterized in that, The first system service is used to provide one or more of the following functions: process management, memory management, file system, device driver, and network services.

9. A system service invocation device, characterized in that, The device is used to implement a kernel under a microkernel architecture, and the device includes: a transceiver module and a processing module; When the transceiver module receives a first call request from the first thread, the processing module is used to establish a connection with the execution entity of the first system service to call the execution entity to process the first call request, wherein the first call request is used to request to call the first system service; When the execution entity returns the processing result, the transceiver module is used to return the processing result to the first thread, and the processing module is also used to update the state of the execution entity to the managed state, wherein the connection between the execution entity and the kernel in the managed state will not be cleaned up, and the execution entity has a corresponding relationship with the first thread; When the transceiver module receives a second call request from the first thread, the processing module is further configured to process the second call request by calling the execution entity based on the correspondence and the connection. The second call request is used to request to call the first system service.

10. The apparatus according to claim 9, characterized in that, After the transceiver module returns the processing result to the first thread, the processing module is further configured to update the state of the first thread to a state corresponding to a managed entity, wherein the state corresponding to a managed entity is used to indicate that the first thread has a corresponding managed execution entity. When the transceiver module receives a second call request from the first thread, the processing module is further configured to determine, based on the state of the first thread, to call the execution entity in a managed state to process the second call request.

11. The apparatus according to claim 9 or 10, characterized in that, When the transceiver module receives a third call request from the first thread, the processing module is also used to clean up the connection with the execution entity and update the state of the execution entity to a dormant waiting state, wherein the third call request is used to request to call the second system service, and the execution entity in the dormant waiting state can be called by other threads; The processing module is also used to call 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 to record the correspondence between the first thread and the execution entity of the second system service.

12. The apparatus according to claim 9 or 10, characterized in that, When the transceiver module receives a fourth call 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 the state of the execution entity to a dormant waiting state, wherein the fourth call request is used to request to call the first system service; The processing module is also used to call other execution entities to process the fourth call request by establishing a connection with other execution entities of the first system service, and to record the correspondence between the first thread and the other execution entities.

13. The apparatus according to any one of claims 9-12, characterized in that, The first thread corresponds to a managed execution entity at any given time.

14. The apparatus according to any one of claims 9-13, characterized in that, The first system service is in a privileged or non-privileged state.

15. The apparatus according to any one of claims 9-14, characterized in that, The connection between the execution entity and the kernel is an IPC connection.

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

17. A system service invocation device, characterized in that, The device includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, wherein when the code is executed, the device performs the method as described in any one of claims 1 to 8.

18. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed by the computer, cause the computer to perform the method according to any one of claims 1 to 8.

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

Images