A microkernel operating system and a method for processing inter-process messages
By introducing inter-process communication and message dispatch daemons in a microkernel operating system, the problems of excessive thread preparation and complex mutex lock settings in existing technologies are solved, achieving efficient request message processing and reducing system overhead.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZEBRED NETWORK TECH CO LTD
- Filing Date
- 2022-09-22
- Publication Date
- 2026-06-05
AI Technical Summary
Existing microkernel operating system service processes require a large number of threads to be prepared in advance to handle request messages, and mutex locks need to be set to solve the problem of multi-threaded concurrent access to devices, resulting in high overhead and development complexity.
It employs an inter-process communication daemon thread and a message dispatch daemon thread to receive request messages from user processes through a microkernel, parse, process, and save them to the corresponding message dispatch daemon thread list, and access devices in priority order, reducing the number of threads and eliminating the need to set mutex locks.
It reduces the overhead and development complexity of microkernel operating systems, improves the efficiency of request message processing, and avoids the problem of multi-threaded concurrent access to devices.
Smart Images
Figure CN115495262B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive control, and more particularly to a microkernel operating system and a method for processing inter-process messages. Background Technology
[0002] A microkernel operating system, as an operating system based on a microkernel architecture, retains only functions such as inter-process communication (IPC), memory management unit (MMU), and process scheduling in the microkernel, while moving other functions to user space to be implemented as service processes. This ensures strong isolation between service processes, giving the microkernel operating system a high degree of stability and reliability.
[0003] In existing microkernel operating systems, such as QNX, when a user process sends a request message to a service process through the microkernel, each request message sent by the user process requires a separate thread from the service process to process it until the processing result is returned.
[0004] In other words, in existing technologies, regardless of the number of request messages to be processed, the service processes of microkernel operating systems need to prepare a large number of threads in advance to handle request messages. In addition, mutex locks need to be set to solve the problem of multi-threaded concurrent access to devices, resulting in high overhead and high development complexity for microkernel operating systems. Summary of the Invention
[0005] This application provides a microkernel operating system and a method for processing inter-process messages, which solves the problems of high overhead and high development complexity in the microkernel operating system, where the service process of the microkernel operating system needs to prepare a large number of threads in advance to process request messages, and also needs to set mutex locks to solve the problem of multi-threaded concurrent access to the device.
[0006] Firstly, this application provides a microkernel operating system, including user processes, a microkernel, and service processes, wherein the service processes include an inter-process communication daemon thread and a message dispatch daemon thread; wherein...
[0007] The inter-process communication daemon thread is used to receive request messages sent by the user process through the microkernel; wherein the request message is a request message generated and prioritized by the user process.
[0008] The inter-process communication daemon thread is also used to parse and process the request message, determine the operation behavior type of the request message, and save the request message to the request message list used by the message distribution daemon thread corresponding to the operation behavior type of the request message;
[0009] The message distribution daemon thread is used to access and process the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0010] In the preferred technical solutions of the aforementioned microkernel operating system,
[0011] The service process is used to call a first registration interface once and a second registration interface at least once, depending on the type of the device, to create the inter-process communication daemon thread and at least one message distribution daemon thread.
[0012] In the preferred technical solution of the above microkernel operating system, when the device type is serial execution type, the service process is specifically used for:
[0013] Call the second registration interface once to create a message distribution daemon thread;
[0014] Call the first registered interface once to create an inter-process communication daemon thread.
[0015] In the preferred technical solution of the above microkernel operating system, when the device type is concurrently executable, the service process is specifically used for:
[0016] Call the second registration interface at least once to create at least one message distribution daemon thread; wherein the number of message distribution daemon threads created can be set through the second registration interface;
[0017] Call the first registered interface once to create an inter-process communication daemon thread.
[0018] In the preferred technical solution of the microkernel operating system described above, the message distribution daemon thread is further used to feed back the result of accessing the device to the user process through the microkernel.
[0019] Secondly, this application provides a method for processing inter-process messages in a microkernel operating system, applied to a service process, wherein the service process includes an inter-process communication daemon thread and a message dispatch daemon thread, and the method includes:
[0020] The inter-process communication daemon thread receives request messages sent by user processes through a microkernel; wherein, the request message is a request message generated and prioritized by the user process.
[0021] The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message distribution daemon thread corresponding to the operation behavior type of the request message;
[0022] The message distribution daemon thread accesses and processes the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0023] In the preferred technical solution of the above-mentioned inter-process message processing method in a microkernel operating system, the following further applies:
[0024] The service process calls a first registration interface once and a second registration interface at least once, depending on the type of the device, to create the inter-process communication daemon thread and at least one message distribution daemon thread.
[0025] In the preferred embodiment of the inter-process message processing method of the aforementioned microkernel operating system, when the device type is serial execution type, the service process calls a first registration interface once and a second registration interface at least once, according to the device type, to create the inter-process communication daemon thread and at least one message dispatch daemon thread, specifically including:
[0026] Call the second registration interface once to create a message distribution daemon thread;
[0027] Call the first registered interface once to create an inter-process communication daemon thread.
[0028] In the preferred embodiment of the inter-process message processing method of the aforementioned microkernel operating system, when the device type is a concurrently executable type, the service process, according to the device type, calls a first registration interface once and a second registration interface at least once to create the inter-process communication daemon thread and at least one message dispatch daemon thread, specifically including:
[0029] Call the second registration interface at least once to create at least one message distribution daemon thread; wherein the number of message distribution daemon threads created can be set through the second registration interface;
[0030] Call the first registered interface once to create an inter-process communication daemon thread.
[0031] In the preferred technical solution of the above-mentioned inter-process message processing method in a microkernel operating system, the following further applies:
[0032] The message distribution daemon thread will feed back the results of accessing the device to the user process through the microkernel.
[0033] This application provides a microkernel operating system and a method for processing inter-process messages. The microkernel operating system includes user processes, a microkernel, and service processes. The service processes include two types of threads: an inter-process communication (IPC) daemon thread and a message dispatch daemon thread. The IPC daemon thread receives request messages generated and prioritized by the user processes, sent by the user processes through the microkernel. The IPC daemon thread parses and processes the request messages, determines the operation type of the request message, and dispatches the request message to the message dispatch daemon thread bound to the operation type of the request message. During the dispatching of request messages by the IPC daemon thread, the IPC daemon thread saves the request message to a request message list corresponding to the operation type of the request message, and wakes up one of the message dispatch daemon threads bound to the operation type of the request message. This woken message dispatch daemon thread retrieves the highest priority request message from the request message list in descending order of priority and performs access processing on the device corresponding to the service process. Compared to existing technologies, where microkernel operating systems require a large number of threads to handle request messages and mutexes to handle concurrent access to devices, resulting in high overhead and development complexity, this application only needs to utilize inter-process communication daemons and dispatch daemons to handle a large number of request messages, thus reducing the overhead of the microkernel operating system. Furthermore, this application eliminates the need for mutexes; by processing request messages according to their operation type and priority, it solves the problem of concurrent access to devices by multiple threads, further reducing the development complexity of the microkernel operating system. Attached Figure Description
[0034] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0035] Figure 1 This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 1 of this application;
[0036] Figure 2This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 4 of this application;
[0037] Figure 3 This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 5 of this application;
[0038] Figure 4 A flowchart illustrating an embodiment of a method for processing inter-process messages in a microkernel operating system provided in this application;
[0039] Figure 5 A flowchart illustrating a second embodiment of a method for processing inter-process messages in a microkernel operating system provided in this application;
[0040] Figure 6 A flowchart illustrating a third embodiment of a method for processing inter-process messages in a microkernel operating system provided in this application;
[0041] Figure 7 This is a flowchart illustrating Embodiment 4 of a method for processing inter-process messages in a microkernel operating system provided in this application. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of 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, not all embodiments. Based on the embodiments of this application, all other embodiments made by those skilled in the art under the guidance of these embodiments are within the scope of protection of this application.
[0043] 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 particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0044] In the automotive control field, the QNX operating system is primarily used. Currently, QNX's Remote Procedure Call (RPC) remains the mainstream solution for in-vehicle real-time operating systems (RTOS). Taking a driver device as an example, during device initialization, an inter-process communication (IPC) thread pool is requested. When an app client accesses a driver server, it sends "requests" such as open / read / write / close via IPC. Each "request" wakes up one thread from the pre-registered thread pool on the driver server for processing. After the thread completes its access to the device, it returns the success or failure result to the app client via IPC and then waits for the next "request." Thus, each "request" occupies one thread. A large number of threads result in high system overhead, and the concurrency of multiple threads accessing the device requires mechanisms such as locking or First-In-First-Out (FIFO) to address this concurrency issue. However, using mechanisms such as locking or FIFO increases the complexity of driver development and can easily introduce unreliable problems such as deadlocks.
[0045] Based on the above technical problems, the technical conception process of this application is as follows: In a microkernel operating system, when using threads to complete the work of a service process, how can we ensure the real-time return of requests while effectively reducing the overhead caused by multithreading and the development complexity caused by setting mutex locks?
[0046] The technical solution of this application will now be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.
[0047] Figure 1 This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 1 of this application. See also... Figure 1 The microkernel operating system 10 includes: user process 101, microkernel 102, and service process 103.
[0048] In this embodiment, the microkernel operating system 10 can be the QNX operating system or other operating systems, and this application does not limit it in this regard.
[0049] Additionally, service process 103 may include an inter-process communication daemon thread 104 and a message dispatch daemon thread 105. It should be noted that... Figure 1Only one message distribution daemon thread is shown in the example. In actual applications, the number of message distribution daemon threads can be determined depending on the type of device. This application does not limit the number of such threads.
[0050] More specifically, when user process 101 needs to access the device corresponding to service process 103, user process 101 generates a request message including the ID value of service process 103 (the channel of service process 103) and sets the priority of the request message. For example, the request message can be a read request or a write request. The user process sends the priority-set request message to microkernel 102 through the Portable Operating System Interface (POSIX).
[0051] After receiving the request message sent by the user process 101, the microkernel 102 obtains the ID value of the service process 103 in the request message, and sends the request message to the service process 103 corresponding to the ID value.
[0052] The inter-process communication daemon thread 104 in service process 103 is awakened when it receives a request message sent by microkernel 102, and parses the request message to determine the operation type of the request message. Specifically, when the request message is a read request, the operation type of the request message is read; when the request message is a write request, the operation type of the request message is write. After determining the operation type of the request message, the inter-process communication daemon thread 104 saves the request message to a shared request message list of all message distribution daemons bound to the operation type of the request message, and simultaneously awakens one of the message distribution daemons. Understandably, the message distribution daemon thread awakened here can be message distribution daemon thread 105.
[0053] The message distribution daemon thread 105 uses a request message list that stores pending request messages. The awakened message distribution daemon thread 105 accesses the device corresponding to the service process 103 in descending order of priority of the request messages in the request message list.
[0054] It should be noted that the device in the embodiments of this application can be a hardware device or a virtual device, and the embodiments of this application do not limit the category to which the device belongs.
[0055] In this embodiment, the microkernel operating system includes user processes, a microkernel, and service processes. The service processes include two types of threads: inter-process communication (IPC) daemons and message distribution daemons. The IPC daemons receive request messages generated and prioritized by the user processes, sent by the user processes through the microkernel. The IPC daemons parse and process the request messages, determine the operation type of the request message, and distribute the request message to the message distribution daemons bound to the operation type of the request message. During the distribution of request messages by the IPC daemons, the IPC daemons save the request message to a request message list corresponding to the operation type of the request message, and wake up one of the message distribution daemons bound to the operation type of the request message. This woken message distribution daemon retrieves the request message with the highest priority from the request message list, in descending order of priority, and performs access processing on the device corresponding to the service process. Compared to existing technologies, where microkernel operating systems require a large number of threads to handle request messages and mutexes to handle concurrent access to devices, resulting in high overhead and development complexity, this application only needs to utilize inter-process communication daemons and dispatch daemons to achieve the merging, scheduling, and rapid processing of request messages, thus reducing the overhead of the microkernel operating system. Furthermore, this application eliminates the need for mutexes; by processing request messages according to their operation type and priority, it solves the problem of concurrent access to devices by multiple threads, further reducing the development complexity of the microkernel operating system.
[0056] The following example illustrates in detail the process of creating an inter-process communication daemon thread and a message dispatch daemon thread for the service process.
[0057] It should be noted that in this embodiment, the service process creates at least one message distribution daemon thread. For ease of explanation, this embodiment is only applicable to the above. Figure 1 The diagram shown below illustrates the structure of a microkernel operating system. The number of message dispatch daemons created should be determined based on the specific circumstances.
[0058] When service process 103 calls the first registration interface, it can create an inter-process communication daemon thread. Optionally, the number of times service process 103 calls the first registration interface can be the number of inter-process communication daemon threads created by service process 103.
[0059] When service process 103 calls the second registration interface, it can create at least one message distribution daemon thread. Optionally, the number of message distribution daemon threads created by service process 103 can be set by the parameters of service process 103 calling the second registration interface.
[0060] It should be noted that the first registration interface and the second registration interface can be different registration interfaces or the same registration interface. When the first registration interface and the second registration interface are the same registration interface, service process 103 can create an inter-process communication daemon thread when it calls the registration interface for the first time, and can create a message distribution daemon thread when it calls the registration interface again.
[0061] Specifically, during the initialization of the microkernel operating system 10 (i.e., during the initialization of the service process 103), the service process 103 can call the first registration interface once to create an inter-process communication daemon thread 104, and call the second registration interface at least once to create at least one message distribution daemon thread, depending on the type of the device corresponding to the service process 103.
[0062] Additionally, it should be noted that service process 103 can also call the third registration interface once to create an inter-process communication channel (i.e., the ID value of service process 103) for service process 103, so that microkernel 102 can send the request message to the inter-process communication daemon thread 104 of service process 103 based on the ID value of service process 103 in the request message sent by user process 101.
[0063] Furthermore, it should be noted that when there is only one device, the inter-process communication (IPC) function of a microkernel operating system can mount one device node; when there are multiple devices, the IPC function of a microkernel operating system can mount multiple device nodes. Each device node corresponds to one IPC daemon thread and at least one message dispatch daemon thread.
[0064] In this embodiment, the service process can create an inter-process communication daemon thread and a message distribution daemon thread that conform to the characteristics of the corresponding device by calling the first registration interface and the second registration interface during initialization. This allows the inter-process communication daemon thread to quickly distribute and process request messages, and the message distribution daemon thread to access and process the device corresponding to the service process sequentially according to the priority of the request messages in the request message list from high to low. Compared with existing microkernel operating systems (such as QNX), which require the service process to pre-create a large number of threads to process request messages, the microkernel operating system of this application reduces the number of threads that need to be created, thereby reducing the overhead of the microkernel operating system. This solves the technical problem of existing microkernel operating systems requiring the service process to pre-create a large number of threads to process a large number of request messages in a timely manner, resulting in high overhead in the microkernel operating system. In addition, this application does not require setting a mutex lock. By processing request messages according to operation behavior type and priority, the problem of multi-threaded concurrent access to the device can be solved, reducing the development complexity of the microkernel operating system.
[0065] The following example illustrates the situation where the device corresponding to service process 103 is of the serial execution type, and service process 103 creates inter-process communication daemon thread 104 and message distribution daemon thread 105.
[0066] This embodiment is applied to Figure 1 The diagram shows the structure of a microkernel operating system.
[0067] When the microkernel operating system 10 is initialized, the service process 103 can call the first registration interface once to create an inter-process communication daemon thread 104, and call the second registration interface once to create a message dispatch daemon thread, depending on the type of the device corresponding to the service process 103.
[0068] With only one message dispatch daemon thread created in service process 103, since the device is a serial execution type and all messages need to be executed serially, the inter-process communication daemon thread 104 can save the request message sent by the microkernel 102 in the request message list used by the message dispatch daemon thread 105 when it receives the request message. The message dispatch daemon thread 105 then accesses and processes the device corresponding to service process 103 according to the priority of the request messages in the request message list from high to low.
[0069] It should be noted that after the message distribution daemon thread 105 accesses the device corresponding to the service process 103 according to the request message, it can also feed back the result of the device access to the user process 101 through the microkernel 102.
[0070] For example, when the device is a Serial Peripheral Interface (SPI) device, since the device can only execute requests serially, during the initialization of the microkernel operating system 10, the service process 103 corresponding to the SPI device calls the first registration interface once to create an inter-process communication daemon thread 104, and calls the second registration interface once to create a message dispatch daemon thread. When the inter-process communication daemon thread 104 receives a request message sent by the microkernel 102, it sends the request message to the request message list corresponding to the message dispatch daemon thread 105. The message dispatch daemon thread 105 then processes the access to the device corresponding to the service process 103 according to the priority of the request messages in the request message list from high to low.
[0071] In this embodiment, when the device type is serial execution, the service process can call the first registration interface once to create an inter-process communication daemon thread, and call the second registration interface once to create a message distribution daemon thread. Compared to the prior art, which requires a thread for each request message, meaning the service process in the microkernel operating system needs to pre-create a large number of threads to handle a large number of request messages in a timely manner, resulting in high overhead for the microkernel operating system, this application only requires two threads to process messages, reducing thread overhead. Furthermore, compared to the prior art, which requires setting mutexes or first-in-first-out queues to avoid thread contention for resources, leading to high development complexity and deadlock issues, this application does not require mutexes. All request messages are processed by a single message distribution daemon thread according to the priority of the request messages. This avoids multiple threads competing for resources, reduces the development complexity of the service process, and ensures that higher-priority request messages receive faster responses.
[0072] The following example, exemplified by Example 4, illustrates the situation where the service process creates an inter-process communication daemon thread and a message dispatch daemon thread when the device corresponding to the service process is of the concurrent execution type.
[0073] Figure 2 This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 4 of this application. See also... Figure 2 The microkernel operating system 20 includes: user process 201, microkernel 202, and service process 203.
[0074] In this embodiment, service process 203 includes an inter-process communication daemon thread 204 and a message dispatch daemon thread ( Figure 2 Two message dispatch daemons are shown, namely message dispatch daemon 205 and message dispatch daemon 206.
[0075] Assuming the device type corresponding to service process 203 is concurrently executable, when the microkernel operating system 20 initializes, service process 203 can call the first registration interface once to create an inter-process communication daemon thread 204, and call the second registration interface twice, with the thread creation count set to 1 for each call, to create two message dispatch daemon threads—message dispatch daemon thread 205 (dispatch out) and message dispatch daemon thread 206 (dispatch in). Message dispatch daemon thread 205 handles read requests, and message dispatch daemon thread 206 handles write requests.
[0076] When the inter-process communication daemon thread 204 receives a request message from the microkernel 202, it parses and processes the request message to determine whether the operation type of the request message is a read or write type. After determining the operation type of the request message, the inter-process communication daemon thread 204 can send the request message to the request message list shared by the message dispatch daemon thread corresponding to the operation type of the request message.
[0077] For example, when the inter-process communication daemon thread 204 determines that the operation type of the request message is a read type, it can send the request message to the request message list used by the message distribution daemon thread 205. The message distribution daemon thread 205 then processes the access to the device corresponding to the service process 203 according to the priority of the request messages in the request message list from high to low.
[0078] It should be noted that after the message distribution daemon thread 205 accesses the device corresponding to the service process 203 according to the request message, it can also feed back the result of the device access to the user process 201 through the microkernel 202.
[0079] Taking a Controller Area Network (CAN) device as an example, since this device can execute requests concurrently, during the initialization of the microkernel operating system 20, the service process 203 corresponding to the CAN device calls the first registration interface once to create an inter-process communication daemon thread 204, and calls the second registration interface twice to create two message distribution daemon threads (message distribution daemon thread 205 and message distribution daemon thread 206). Message distribution daemon thread 205 is responsible for processing read requests according to the priority of the request messages, while message distribution daemon thread 206 is responsible for processing write requests according to the priority of the request messages. When the inter-process communication daemon thread 204 parses the request message and determines that the operation type of the request message is write, it can send the request message to the request message list used by message distribution daemon thread 206. Message distribution daemon thread 206 then performs write processing on the CAN device corresponding to service process 203 according to the request messages in the request message list, from highest to lowest priority.
[0080] In this embodiment, when the device type is concurrently executable, the service process can call the first registration interface once to create an inter-process communication daemon thread, and call the second registration interface twice to create two message dispatch daemon threads. Compared to existing microkernel operating systems (such as QNX), which require a thread for each request message and need to pre-create a large number of threads to handle a large number of request messages, resulting in high overhead, the microkernel operating system of this application only requires three threads to process messages, reducing thread overhead. Furthermore, compared to existing microkernel operating systems that require device mutexes or first-in-first-out queues to avoid thread contention for resources, leading to high development complexity and deadlock issues, in the microkernel operating system of this application, one message dispatch daemon thread handles only read requests, and another message dispatch daemon thread handles only write requests. Each message dispatch daemon thread processes request messages according to priority, ensuring timely message processing without the need for mutexes or first-in-first-out queues, thus avoiding thread contention for resources and reducing the development complexity of the service process.
[0081] In addition, it should be noted that, based on the above embodiments, this application can be flexibly compatible with serial devices such as SPI and device drivers that can be accessed in parallel.
[0082] The following example, exemplified by Example 5, illustrates another scenario where the service process creates an inter-process communication daemon thread and a message dispatch daemon thread when the device corresponding to the service process is of the concurrently executable type.
[0083] Figure 3 This is a schematic diagram of the structure of a microkernel operating system provided in Embodiment 5 of this application. See also... Figure 3 The microkernel operating system 30 includes: user process 301, microkernel 302, and service process 303.
[0084] In this embodiment, service process 303 includes inter-process communication daemon thread 304 and message dispatch daemon thread ( Figure 3 Three message dispatch daemons are shown: message dispatch daemon 305, message dispatch daemon 306, and message dispatch daemon 307.
[0085] Because the device corresponding to service process 303 processes request messages frequently, and the number of write requests processed is greater than the number of read requests processed, when the microkernel operating system 303 initializes, assuming the device type corresponding to service process 303 is concurrently executable, service process 303 can call the first registration interface once to create an inter-process communication daemon thread 304, and call the second registration interface at least once to create three message dispatch daemon threads, namely message dispatch daemon thread 305 (dispatch out), message dispatch daemon thread 306 (dispatch in), and message dispatch daemon thread 307 (dispatch in). Message dispatch daemon thread 305 is responsible for handling read requests, message dispatch daemon thread 306 is responsible for handling write requests, and message dispatch daemon thread 307 is responsible for handling write requests. Understandably, the number of message dispatch daemon threads created by service process 303 during the process of calling the second registration interface at least once to create the three message dispatch daemon threads can be set by the parameters of the second registration interface called by service process 303. Optionally, the number of threads created can be set to 3, meaning that calling the second registration interface once is sufficient to create three message distribution daemon threads. Alternatively, the number of threads created can be set to 1, meaning that calling the second registration interface three times is sufficient to create three message distribution daemon threads.
[0086] When the inter-process communication daemon thread 304 receives a request message sent by the microkernel 302, it parses and processes the request message to determine whether the operation type of the request message is a read type or a write type. After determining that the operation type of the request message is a write type, the inter-process communication daemon thread 304 can save the request message in the request message list shared by the message dispatch daemon thread 306 and the message dispatch daemon thread 307.
[0087] Additionally, it should be noted that when the device corresponding to service process 303 processes request messages frequently, service process 303 can call the second registration interface to create at least four message distribution daemon threads when creating the message distribution daemon thread. This embodiment does not limit the number of message distribution daemon threads created; it depends on the specific circumstances.
[0088] In this embodiment, when the device type is concurrently executable, the service process can call the first registration interface once to create an inter-process communication daemon thread, and call the second registration interface to create three message dispatch daemon threads. Compared to existing microkernel operating systems (such as QNX), which require a thread for each request message and need to pre-create a large number of threads to handle a large number of request messages, resulting in high overhead, the microkernel operating system of this application requires relatively fewer threads, reducing thread overhead. Furthermore, in this application, each message dispatch daemon thread processes request messages according to priority, ensuring the timeliness of message processing.
[0089] Figure 4 This is a flowchart illustrating an embodiment of a method for handling inter-process messages in a microkernel operating system provided in this application. This method embodiment can be applied to the above-mentioned... Figure 1 or Figure 2 The service process shown includes an inter-process communication daemon thread and a message dispatch daemon thread. For example... Figure 4 As shown, the inter-process message processing method of this microkernel operating system specifically includes the following steps:
[0090] Step S401: The inter-process communication daemon thread receives request messages sent by user processes through the microkernel.
[0091] Among them, the request message is a request message generated and prioritized by the user process.
[0092] Step S402: The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message dispatch daemon thread corresponding to the operation behavior type of the request message.
[0093] Step S403: The message distribution daemon thread accesses and processes the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0094] In this embodiment, the inter-process communication (IPC) daemon thread receives request messages sent by user processes through the microkernel. These request messages are generated and prioritized by the user processes. The IPC daemon thread parses and processes the request messages, determines the operation type of the request message, and distributes the request message to the message distribution daemon thread bound to the operation type of the request message. During the distribution of request messages by the IPC daemon thread, the IPC daemon thread saves the request message to a request message list corresponding to the operation type of the request message, and wakes up one of the message distribution daemon threads bound to the operation type of the request message. This woken-up message distribution daemon thread is used to retrieve the request message with the highest priority in the request message list, from highest to lowest priority, and perform access processing on the device corresponding to the service process. Compared to the prior art, where the service process of a microkernel operating system needs to pre-create a large number of threads to process request messages and also needs to set mutex locks to solve the problem of multi-threaded concurrent access to devices, resulting in high overhead and high development complexity for the microkernel operating system, this application only needs to use the IPC daemon thread and the distribution daemon thread to process a large number of request messages, reducing the overhead of the microkernel operating system. In addition, this application does not require setting a mutex lock. By processing request messages according to their operation behavior type and priority, the problem of multi-threaded concurrent access to the device can be solved, reducing the development complexity of microkernel operating systems.
[0095] Figure 5 This is a flowchart illustrating a second embodiment of a method for handling inter-process messages in a microkernel operating system provided in this application. This method embodiment can be applied to the above-mentioned... Figure 1 or Figure 2 The service process shown includes an inter-process communication daemon thread and a message dispatch daemon thread. For example... Figure 5 As shown, the inter-process message processing method of this microkernel operating system specifically includes the following steps:
[0096] Step S501: The service process calls the first registration interface once and the second registration interface at least once, depending on the type of the device, to create an inter-process communication daemon thread and at least one message dispatch daemon thread.
[0097] It should be noted that the service process needs to call the second registration interface at least once to create the message distribution daemon thread, and then call the first registration interface once to create the inter-process communication daemon thread. That is, the service process needs to create the message distribution daemon thread before creating the inter-process communication daemon thread, so that the inter-process communication daemon thread can receive and parse request messages when it is created.
[0098] Step S502: The inter-process communication daemon thread receives request messages sent by user processes through the microkernel.
[0099] Among them, the request message is a request message generated and prioritized by the user process.
[0100] Step S503: The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message dispatch daemon thread corresponding to the operation behavior type of the request message.
[0101] Step S504: The message distribution daemon thread accesses and processes the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0102] Step S505: The message dispatch daemon thread feeds back the results of accessing the device to the user process through the microkernel.
[0103] In this embodiment, the service process can create an inter-process communication daemon thread and a message distribution daemon thread that conform to the characteristics of the corresponding device through the first registration interface and the second registration interface during initialization. This allows the inter-process communication daemon thread to quickly distribute request messages, and the message distribution daemon thread to access the device corresponding to the service process sequentially according to the priority of the request messages in the request message list from high to low. Compared to the prior art, where the service process of a microkernel operating system needs to pre-create a large number of threads to handle request messages and also needs to set mutex locks to solve the problem of multi-threaded concurrent access to the device, resulting in high overhead and development complexity for the microkernel operating system, this application only needs to use one inter-process communication daemon thread and at least one distribution daemon thread to handle a large number of request messages, reducing the overhead of the microkernel operating system. In addition, this application does not require setting mutex locks. By processing request messages according to their operation behavior type and priority, the problem of multi-threaded concurrent access to the device can be solved, further reducing the development complexity of the microkernel operating system.
[0104] Figure 6 This is a flowchart illustrating a third embodiment of a method for handling inter-process messages in a microkernel operating system provided in this application. This method embodiment can be applied to the above-mentioned... Figure 1 The service process shown.
[0105] Step S601: The service process calls the second registration interface once to create a message distribution daemon thread.
[0106] Step S602: The service process calls the first registration interface once to create an inter-process communication daemon thread.
[0107] Step S603: The inter-process communication daemon thread receives request messages sent by user processes through the microkernel.
[0108] Among them, the request message is a request message generated and prioritized by the user process.
[0109] Step S604: The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message dispatch daemon thread corresponding to the operation behavior type of the request message.
[0110] Step S605: The message distribution daemon thread accesses and processes the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0111] In this embodiment, when the device type is serial execution, the service process can call the first registration interface once to create an inter-process communication daemon thread, and call the second registration interface once to create a message dispatch daemon thread. Compared to the prior art, which requires a thread for each request message, meaning the service process in the microkernel operating system needs to pre-create a large number of threads to handle request messages, resulting in high overhead for the microkernel operating system, this application only requires two threads to process messages, reducing thread overhead. Furthermore, compared to the prior art, which requires setting mutex locks or first-in-first-out queues to avoid thread contention for resources, leading to high development complexity and a high risk of deadlock, in this application, all request messages are processed by a single message dispatch daemon thread of the microkernel operating system according to the priority of the request messages, avoiding multiple threads competing for resources and reducing the development complexity of the service process.
[0112] Figure 7 This is a flowchart illustrating a fourth embodiment of a method for handling inter-process messages in a microkernel operating system provided in this application. This method embodiment can be applied to the above-mentioned... Figure 2 The service process shown.
[0113] Step S701: The service process calls the second registration interface at least once to create at least one message distribution daemon thread.
[0114] The number of message distribution daemon threads to be created can be set through the second registration interface.
[0115] Step S702: The service process calls the first registration interface once to create an inter-process communication daemon thread.
[0116] Step S703: The inter-process communication daemon thread receives request messages sent by user processes through the microkernel.
[0117] Among them, the request message is a request message generated and prioritized by the user process.
[0118] Step S704: The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message dispatch daemon thread corresponding to the operation behavior type of the request message.
[0119] Step S705: The message distribution daemon thread accesses and processes the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread.
[0120] In this embodiment, when the device type is concurrently executable, the service process can call the first registration interface once to create an inter-process communication daemon thread, and call the second registration interface at least once to create at least one message dispatch daemon thread. Compared to the existing microkernel operating system, which requires a thread for each request message, necessitating the pre-creation of a large number of threads to handle request messages and resulting in high overhead, the microkernel operating system of this application only requires a small number of threads to process messages, reducing thread overhead. Furthermore, compared to the existing microkernel operating system (such as QNX) which requires device mutexes or first-in-first-out queues to avoid resource contention leading to high development complexity and deadlock issues, this application allows for the placement of serially executed request messages in a request message list used by one message dispatch daemon thread, and concurrently executable request messages in a request message list used by other message dispatch daemon threads. Each message dispatch daemon thread processes request messages according to priority, ensuring message processing timeliness while reducing the development complexity of the service process.
[0121] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A microkernel operating system, comprising user processes, a microkernel, and service processes, characterized in that, The service process includes an inter-process communication daemon thread and at least one message dispatch daemon thread; wherein... The inter-process communication daemon thread is used to receive request messages sent by the user process through the microkernel; wherein the request message is a request message generated and prioritized by the user process. The inter-process communication daemon thread is also used to parse and process the request message, determine the operation behavior type of the request message, and save the request message to the request message list used by the message distribution daemon thread corresponding to the operation behavior type of the request message; The message distribution daemon thread corresponding to each operation behavior type is used to access the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread, so that the access processing of the device does not require the use of a mutex lock.
2. The microkernel operating system according to claim 1, characterized in that, The service process is configured to call a first registration interface once and a second registration interface at least once, depending on the type of the device, to create an inter-process communication daemon thread and at least one message distribution daemon thread.
3. The microkernel operating system according to claim 2, characterized in that, When the device is of type serial execution, the service process is specifically used for: Call the second registration interface once to create a message distribution daemon thread; Call the first registered interface once to create an inter-process communication daemon thread.
4. The microkernel operating system according to claim 2, characterized in that, When the device type is concurrent execution type, the service process is specifically used for: Call the second registration interface at least once to create at least one message distribution daemon thread; wherein the number of message distribution daemon threads created can be set through the second registration interface; Call the first registered interface once to create an inter-process communication daemon thread.
5. The microkernel operating system according to any one of claims 1-4, characterized in that, The message distribution daemon thread is also used to feed back the results of accessing the device to the user process through the microkernel.
6. A method for processing inter-process messages in a microkernel operating system, characterized in that, Applied to a service process, the service process including an inter-process communication daemon thread and at least one message dispatch daemon thread, the method includes: The inter-process communication daemon thread receives request messages sent by user processes through a microkernel; wherein, the request message is a request message generated and prioritized by the user process. The inter-process communication daemon thread parses and processes the request message, determines the operation behavior type of the request message, and saves the request message to the request message list used by the message distribution daemon thread corresponding to the operation behavior type of the request message; The message distribution daemon thread corresponding to each operation behavior type accesses the device corresponding to the service process in descending order of priority of the request messages in the request message list used by the message distribution daemon thread, so that the access processing of the device does not require the use of mutex locks.
7. The method for processing inter-process messages in a microkernel operating system according to claim 6, characterized in that, Also includes: The service process calls a first registration interface once and a second registration interface at least once, depending on the type of the device, to create an inter-process communication daemon thread and at least one message distribution daemon thread.
8. The method for processing inter-process messages in a microkernel operating system according to claim 7, characterized in that, When the device type is serial execution type, the service process, based on the device type, calls a first registration interface once and a second registration interface at least once to create the inter-process communication daemon thread and at least one message distribution daemon thread, specifically including: Call the second registration interface once to create a message distribution daemon thread; Call the first registered interface once to create an inter-process communication daemon thread.
9. The method for processing inter-process messages in a microkernel operating system according to claim 7, characterized in that, When the device type is concurrent execution type, the service process, based on the device type, calls the first registration interface once and the second registration interface at least once to create the inter-process communication daemon thread and at least one message dispatch daemon thread, specifically including: Call the second registration interface at least once to create at least one message distribution daemon thread; wherein the number of message distribution daemon threads created can be set through the second registration interface; Call the first registered interface once to create an inter-process communication daemon thread.
10. The method for processing inter-process messages in a microkernel operating system according to any one of claims 6-9, characterized in that, Also includes: The message distribution daemon thread will feed back the results of accessing the device to the user process through the microkernel.