Microkernel operating system thread communication optimization method, device and system and electronic medium

Abstract

The invention discloses a microkernel operating system thread communication optimization method, device and system and an electronic medium, and aims to reduce code repetition and development complexity and reduce deadlock risks in a multi-resource cooperation scene by constructing a unified communication resource scheduling framework, a standardized blocking mode and an overtime control and wake-up process; through a resource random code verification mechanism, association verification of resources and thread states is established, the situation that the resources are destroyed due to thread blocking operation is avoided, and the resource operation failure rate is greatly reduced; the timeout and resource blocking queues are managed through independent queues, the thread wake-up logic is optimized, and wake-up delay and response jitter are reduced. According to the invention, the stability, the safety and the real-time performance of the system are obviously improved, and the application requirement of high real-time performance in the industrial control field can be met.

Description

Technical Field

[0001] This application belongs to the field of embedded operating system technology, specifically relating to a method, apparatus, system, and electronic medium for optimizing thread communication in a microkernel operating system. Background Technology

[0002] To meet the diverse application scenarios of embedded devices, real-time microkernel operating systems, as the operating platform for embedded devices, need to provide rich inter-thread communication resources, generally including message queues, mailboxes, semaphores, mutexes, event sets, delays, and other resource capabilities. However, when these communication resources are used by different threads, thread scheduling occurs due to resource blocking and satisfaction. These processes are highly coupled, and the resource usage in open-source systems is generally weakly defensive. If the blocking and satisfaction conditions of different types of communication resources are not consistent, and defensive issues are not considered, the overall system mechanism will become complex and chaotic, prone to problems, and increase the difficulty of application development. At the same time, the information of various communication resources is chaotic and inconsistent, making it inconvenient to query and hindering application developers from locating defects.

[0003] The existing technical solutions currently have the following main shortcomings: 1. Fragmented Communication Resource Scheduling Framework. Current mainstream microkernel systems employ independent scheduling implementations for different communication resource types, such as message queues, semaphores, and event sets. Each resource requires its own implementation of blocking management, timeout control, and wake-up handling logic. This architecture results in a large number of modules with duplicated functions in the system code. When new communication resources need to be added, developers must redesign the entire scheduling mechanism, significantly increasing development complexity and time costs. More seriously, in complex scenarios where multiple resources work together, this decentralized management greatly increases the risk of system deadlock.

[0004] 2. Lack of a resource lifecycle safety management mechanism. Traditional solutions fail to establish an effective correlation between resource and thread states, and lack means to verify the validity of resource operations. This allows blocked threads to operate on resources that have already been destroyed, leading to serious errors such as memory overflows and ultimately causing system-level failures. Systems using existing technologies exhibit high resource operation failure rates when operating in industrial settings, failing to meet the functional safety requirements of industrial control systems.

[0005] 3. The system suffers from real-time performance bottlenecks. Since the thread wake-up mechanism relies on traversing the entire ready queue, its time complexity increases linearly with the number of system threads. Furthermore, the response time of high-priority threads exhibits instability, making it unsuitable for applications requiring high safety and reliability, such as industrial settings.

[0006] Therefore, there is an urgent need for a thread communication optimization scheme that can achieve unified management of communication resources, improve security, and support flexible expansion. Summary of the Invention

[0007] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a method, device, system and electronic medium for optimizing thread communication in a microkernel operating system. By constructing a unified communication resource scheduling framework, a resource random code verification mechanism, and an independent queue management timeout and resource blocking queue, it solves the problems of fragmented communication resource scheduling, lack of security mechanisms and insufficient real-time performance in the prior art.

[0008] To achieve the above objectives, this application adopts the following technical solution: a method for optimizing thread communication in a microkernel operating system, comprising: S100: Responding to the event that the thread's request for communication resources is not satisfied, perform resource blocking processing, and set the blocking mode according to the resource type. The blocking mode includes non-waiting blocking, finite-time blocking, or permanent blocking. S200: For finite-time blocking mode, the current thread is attached to the system clock queue and a timeout is enabled; S300: Add the current thread to the resource blocking queue of the target resource; S400: Sets the thread to a blocked state and triggers the thread scheduler to schedule other ready threads; S500: In response to a resource fulfillment event, locate the blocking waiting queue of the target resource; S600: Perform wake-up processing on the first thread of the blocked waiting queue; S700: Add the woken-up thread to the thread's ready queue and switch it to the ready state.

[0009] Furthermore, in S100, when the blocking mode is a non-waiting blocking mode, an error state is immediately returned; When the blocking mode is a permanent blocking mode, skip S200 and execute S300; S200 is only executed in the finite-time blocking mode.

[0010] Furthermore, S400 also includes: S410: Records the identifier and type of the blocked resource; S420: Store the random code generated by the resource management block when the resource is created to the thread control module.

[0011] Furthermore, the S600 also includes: S610: Verify the consistency between the current random code of the resource management block and the random code stored in the thread control module. If the verification fails, terminate the wake-up process.

[0012] Furthermore, the random code is generated in the following ways: Call the kernel security service to generate random numbers; Perform a hash operation or message authentication code algorithm on the random number and the physical address of the resource to generate a random code.

[0013] Furthermore, when the verification fails in S610: Generate a log of unauthorized resource access; Returns a status indicating that the resource has been destroyed to the thread; Skip subsequent wake-up steps.

[0014] Furthermore, the S600 also includes: S620: If a timeout occurs, remove the thread from the system clock queue; S630: Remove the thread from the resource blocking queue; S640: Set the wake-up reason flag and synchronize it to the thread control module.

[0015] The present invention also provides another embodiment, a microkernel operating system thread communication optimization device, comprising: Resource management module: Responds to thread resource unmet event and performs resource blocking processing; or responds to thread resource met event and performs resource wake-up processing; Blocking processing module: Responds to resource blocking processing requests, sets the blocking mode according to the resource type, the blocking mode includes no-wait blocking, finite-time blocking or permanent blocking, and hangs the finite-time blocking thread in the system clock queue and the resource blocking queue. Thread control module: In response to the blocking result, set the current thread to the blocked state and trigger the thread scheduler to schedule other ready threads; or in response to the thread wake-up result, add the woken-up thread to the thread's ready queue and switch it to the ready state. Thread wake-up module: Responds to resource wake-up requests and performs wake-up processing on the first thread in the blocked waiting queue.

[0016] This application also discloses a microkernel operating system thread communication optimization system, including: One or more processors; Computer-readable storage medium for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method according to any one of claims 1 to 7.

[0017] This application also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

[0018] The beneficial effects of this application are: 1. Unified resource scheduling framework: By constructing a unified communication resource scheduling framework, standardizing blocking modes, timeout control and wake-up processes, the complexity of microkernel inter-thread communication development is simplified, the quality of microkernel code is improved, and the uniformity, security and reliability of real-time microkernel operating systems are guaranteed.

[0019] 2. Improved security management mechanism: By establishing a resource random code verification mechanism, the association between resources and thread states is verified to prevent awakened threads from operating invalid resource management blocks, thereby improving the robustness and stability of the microkernel system.

[0020] 3. Timely and efficient system response: The management of blocked threads is maintained independently through clock queues and thread resource blocking queues. Combined with a unified technical framework, thread management during resource blocking is simplified, thread wake-up logic is optimized, and wake-up latency and response jitter are reduced. Attached Figure Description

[0021] This application is described with reference to the following figures: Figure 1 This application shows a microkernel operating system thread state diagram; Figure 2 A table of communication resource classes in this application is shown; Figure 3 The flowchart of the microkernel operating system thread communication optimization method of this application is shown; Figure 4 The flowchart of the thread blocking state operation in this application is shown; Figure 5 The flowchart of the thread wake-up method in this application is shown. Detailed Implementation

[0022] To better explain and facilitate understanding of the present invention, it is described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described below are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other; for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0023] As the background technology indicates, to meet the diverse application scenarios of embedded devices, real-time microkernel operating systems, as the runtime environment for embedded devices, need to provide abundant inter-thread communication resources. These typically include message queues, mailboxes, semaphores, mutexes, event sets, and latency capabilities. Current mainstream microkernel operating systems have significant shortcomings in inter-thread communication, making it difficult to meet the stringent requirements of high-reliability applications. Existing technologies suffer from three key drawbacks: First, communication resource scheduling and management are fragmented, with different resource types employing independent scheduling implementations. This leads to high code duplication, requiring a complete redevelopment of the scheduling mechanism when adding new resources, and significantly increasing the risk of deadlock in multi-resource collaborative scenarios. Second, a resource lifecycle safety management mechanism is lacking, and effective resource operation verification methods are absent, allowing destroyed resources to be operated on again, potentially causing system-level failures. Third, real-time performance is a bottleneck; thread wake-up requires traversing the ready queues of all types of communication resources, which is highly complex and introduces latency, failing to meet the system's real-time requirements.

[0024] like Figure 1 As shown, threads in an embedded real-time microkernel operating system achieve business goals by executing their own logical processes and interacting with environmental resources. Therefore, the design of business threads inevitably requires resource requests and outputs. Thus, the main state machine of an operating system thread generally includes three states: ready, running, and blocked. The ready state indicates that the thread has sufficient resources and is ready to acquire the CPU for work. The running state indicates that the thread has acquired the CPU and is currently performing its work. The blocked state indicates that the running thread is in a state where the aforementioned resource requirements are not met during its execution. To support information transfer and logical collaboration between different business threads, the embedded real-time microkernel operating system provides various types of resources to meet inter-thread communication and synchronization capabilities, such as message queues, event sets, semaphores, mutexes, and delays. See details... Figure 2 .

[0025] This application aims to provide a method, apparatus, system, and electronic medium for optimizing thread communication in a microkernel operating system. By constructing a unified communication resource scheduling framework, a resource random code verification mechanism, and independent queue management of timeout and resource blocking queues, it addresses three core problems in existing technologies: fragmented communication resource scheduling, lack of security mechanisms, and insufficient real-time performance. Specific methods are as follows: Figure 3 As shown, it includes: S100: Responds to events where a thread's request for a communication resource is not satisfied, and performs resource blocking processing. The blocking mode is set according to the resource type, including non-waiting blocking, finite-time blocking, or permanent blocking. When a business application thread uses different types of communication resources such as message queues, event sets, semaphores, mutexes, and delays, and the corresponding resource cannot satisfy the current thread's application needs, resource blocking processing is required. For example, an application thread might use a message queue resource and find that there are no messages in the queue; or a thread might want to use a mutex to operate on critical data and find that the mutex is currently held by another thread. Corresponding to the unsatisfied communication resource request, the blocking mode and blocking reason are set according to the resource type. The blocking modes include non-waiting blocking, finite-time blocking, or permanent blocking.

[0026] S200: For finite-time blocking mode, attach the current thread to the system clock queue and enable timeout.

[0027] S300: Add the current thread to the resource blocking queue of the target resource.

[0028] When a thread becomes blocked, an appropriate blocking mode is determined based on predefined resource configuration information. This predefined resource configuration information includes the real-time requirements of thread resources. For example, a semaphore controlling I / O in the system needs to be synchronized within 10ms; otherwise, the semaphore will expire due to timeout. When such a semaphore becomes blocked, it is configured into a finite-time blocking mode based on its real-time requirements. The current thread is attached to the system clock queue, and a timeout is started. Since the thread needs to be woken up within a finite time, it will relinquish the semaphore resource if the timeout occurs. Therefore, a timeout is set, and the thread is forcibly woken up when the timeout expires. If the thread is still not in a state that meets the requirements and cannot be scheduled normally, the thread resource is discarded.

[0029] For the non-waiting blocking mode, the resource unavailable status is directly written to the status register of the thread control module, and the thread is kept in the ready queue. In the non-waiting blocking mode, after setting the current thread to a blocked state, the thread control module can directly trigger the thread scheduler to call other threads from the ready queue, reducing the impact of thread blocking on the operating system's thread scheduling. For the limited-time blocking mode, the current thread is attached to the system clock queue and a timeout is enabled. For the permanent blocking mode, S200 is skipped and S300 is executed. In the permanent blocking mode, the communication resource will be blocked for a long time; the current thread is directly added to the target resource's resource blocking queue without attaching the thread to the system clock queue. By managing the resource blocking queue through independent system clock queues and the target resource's resource blocking queue, operating system thread blocking is differentiated. For specific blocked threads, the system clock queue is used for management. When the operating system is in a blocked state, it can quickly respond to the blocked thread and release blocked resources for other threads to use.

[0030] S400: Sets the thread to a blocked state and triggers the thread scheduler to schedule other ready threads. When a thread resource is blocked in the time-limited blocking mode, the thread resource is blocked, and then the thread is set to a blocked state. During the time the current thread is waiting for the resource, the CPU is given to other threads that need to process business. At the same time, it is waiting for the resource to be satisfied for the blocked thread to wake it up again.

[0031] Furthermore, such as Figure 4 As shown, when a thread is set to a blocked state, the following steps will also be executed: S410: Records the identifier and type of the blocked resource; S420: Store the random code generated by the resource management block when the resource is created to the thread control module.

[0032] In this example, the random code can invoke the kernel's security service to generate a 256-bit random number. Then, a hash operation is performed on the random number and the resource's physical address to generate an immutable random code character. This random code is synchronously stored in the thread control module, establishing a secure association between the thread and the communication resource. The random code possesses uniqueness and anti-forgery properties; even if resource addresses are reused, the validity of the same type of thread resource can be accurately identified, further enhancing security. Of course, other random code generation methods, such as message authentication code algorithms, can also achieve immutable random code generation, which will not be detailed in this specification.

[0033] S500: In response to a resource fulfillment event, locate the blocking wait queue of the target resource.

[0034] When a resource in a finite-duration blocking mode becomes blocked, the resource is set to a blocked state. During the time the current thread waits for the resource, the CPU is allocated to other threads that need to process the business. When the resource becomes available, the thread control module quickly locates the target resource's blocking queue without traversing all resource blocking queues, achieving fast and accurate resource scheduling and location, and reducing response time. The resource availability event can be triggered by another business thread blocking and releasing the resource, allowing the blocked thread to acquire it; it can also be due to the resource blocking timeout expiring, forcibly waking the blocked thread; it can be forcibly woken up by another business thread; or even by other custom methods.

[0035] S600: Perform wake-up processing on the first thread of the blocked waiting queue. During this process, the consistency between the current random code in the resource management block and the random code stored in the thread control module must be verified. If the verification fails, the wake-up process is terminated. If the wake-up fails: Generate a log of unauthorized resource access; Returns a status indicating that the resource has been destroyed to the thread; Skip subsequent wake-up steps.

[0036] By generating logs for failed wake-up attempts, information about thread resource destruction can be effectively recorded. When maintenance personnel perform system maintenance, they can quickly confirm resource destruction information through the logs and troubleshoot the cause of system anomalies. Simultaneously, upon receiving a resource destruction status, a thread can skip the wake-up step, releasing CPU resources to other threads that need to process business, reducing the impact of thread blocking on system scheduling.

[0037] Furthermore, such as Figure 5 As shown, the wake-up process also includes: S620: If a timeout occurs, remove the thread from the system clock queue; S630: Remove the thread from the resource blocking queue; S640: Set the wake-up reason flag and synchronize it to the thread control module.

[0038] Managing resource blocking through independent system clock queues and resource blocking queues effectively differentiates between thread blocking scenarios. For thread blocking in non-waiting and permanent blocking modes, there's no need to attach to the system clock queue; control is handled directly through the resource blocking queue. For resource blocking in finite-time blocking modes, control is achieved through dual attachment to both the system clock queue and the resource blocking queue. The system clock queue uses a timeout to set thread wake-up modes. When the timeout expires, threads with real-time requirements are forcibly woken up. If wake-up fails due to timeout, related data is discarded, preventing timed-out threads from impacting normal system operation.

[0039] If a thread can be woken up normally, upon waking, it is checked whether the blocked thread has a timeout. If so, the thread is removed from both the system clock queue and the resource blocking queue. If there is no timeout, the thread is blocked in a non-finite-time blocking mode and is not attached to the system clock queue; it only needs to be removed from the resource blocking queue. After successfully waking up a thread, the reason for waking up is synchronized to the thread control module. Reasons for thread waking up include proactive resource release, timeout triggering, and external forced wake-up. Thread blocking scenarios are diverse (e.g., waiting for resource release, waiting for timeout, being forcibly woken up externally), and differentiated logic needs to be executed based on different reasons after waking up. "Setting a wake-up reason" can pass "background information about resource satisfaction" to the thread, ensuring that the thread can respond quickly without additionally querying the resource status, avoiding logical confusion or invalid operations.

[0040] When a thread is woken up and the reason for waking up is "active release of resources", the thread can directly execute the preset "data synchronization logic", such as reading sensor data collected by the I / O module. There is no need to determine whether the resources are available, because the reason for waking up has clearly indicated that the resources have been released normally, reducing the time overhead of thread status query.

[0041] If a thread is woken up due to a timeout caused by "limited-time blocking", the thread does not need to continue waiting for resources and can directly execute "timeout retry logic", such as re-initiating I / O data requests or "business degradation logic", such as using cached historical data, to avoid the thread being woken up for unknown reasons and falling into an infinite loop of "repeated waiting".

[0042] When an emergency failure occurs in an industrial setting, the system can forcibly wake up the blocked "emergency shutdown thread" through external commands. When the reason for the wake-up is "external forced wake-up", the thread can skip the regular resource verification process and directly execute the highest priority "shutdown control logic" to meet the emergency response needs of industrial scenarios.

[0043] By "setting wake-up reason", a complete "blocking-wake-up" traceability can be provided, which greatly reduces development and maintenance costs.

[0044] S700: Add the woken thread to the thread's ready queue and switch it to the ready state. After switching the woken thread to the ready state, the thread control module can schedule the woken thread through the thread's ready queue. In this embodiment, the system I / O semaphore needs to be synchronized within 10ms. When the operating system thread is scheduling the semaphore, if the semaphore has not yet been acquired and there is no semaphore available for scheduling in the ready list, the thread will be blocked due to the lack of a semaphore. At this time, the thread will perform resource blocking processing on the semaphore, setting it to a finite-time blocking mode, loading the thread into the system clock queue, and starting a 10ms timeout. At the same time, for the blocked thread, the kernel security service is called to generate a random code and synchronously store it in the thread management module.

[0045] In this embodiment, after 5ms has elapsed, the system's I / O module, having completed semaphore data acquisition, sets its own thread to the ready state and adds it to the ready queue to await scheduling by the thread control module. While the system is processing other threads, the system's ready queue keeps a timer. When the 10ms timer expires, a resource fulfillment event for the I / O semaphore is triggered, and the I / O semaphore is scheduled via the thread scheduler. This enables rapid location and scheduling of blocked resources, avoiding traversal of all communication resources and reducing scheduling response time. At this time, the thread control module responds to the resource fulfillment event of the I / O semaphore, quickly locates the resource blocking waiting queue of the I / O semaphore, and wakes up the first thread in that queue. Furthermore, during the wake-up process, the consistency between the current random code of the resource management block and the random code stored in the thread control module is verified. Since the random code is generated by combining the physical address of the resource and a random number, it has immutable uniqueness, effectively ensuring resource validity. Even for other resources at the same physical address, the generated random codes will differ due to the different random numbers. If a resource is destroyed or modified for other reasons, a new random code will be generated. When the thread control module wakes up the first thread in the ready queue of that thread, it will terminate the wake-up process due to the different random codes, generate an illegal access log for the resource, and return the resource has been destroyed status, ensuring the traceability of all destroyed resources and facilitating maintenance personnel to quickly locate the cause of the anomaly.

[0046] In summary, the beneficial effects of the method of the present invention are as follows: 1. Unified resource scheduling framework: By constructing a unified communication resource scheduling framework, standardizing blocking modes, timeout control and wake-up processes, the complexity of microkernel inter-thread communication development is simplified, the quality of microkernel code is improved, and the uniformity, security and reliability of real-time microkernel operating systems are guaranteed.

[0047] 2. Improved security management mechanism: By establishing a resource random code verification mechanism, the association between resources and thread states is verified to prevent awakened threads from operating invalid resource management blocks, thereby improving the robustness and stability of the microkernel system.

[0048] 3. Timely and efficient system response: The management of blocked threads is maintained independently through clock queues and thread resource blocking queues. Combined with a unified technical framework, thread management during resource blocking is simplified, thread wake-up logic is optimized, and wake-up latency and response jitter are reduced.

[0049] Another embodiment of the present invention provides a container restart and self-healing device, applied to container management in a Kubernetes cluster, comprising: The strategy configuration module is used to receive user-defined restart strategies, which include fast restart parameters, self-test procedures, self-healing procedures, and fallback procedures. The policy parsing module, connected to the policy configuration module, is used to parse the restart policy and generate executable instructions; The strategy execution module, integrated into the kubelet component of Kubernetes, is used to perform container restart, self-check, self-healing, and fallback operations according to the executable instructions.

[0050] This device, through in-depth modification of the Kubelet core components, constructs an integrated architecture of "policy configuration - fast restart - anomaly self-check - self-healing execution - fallback handling": On the one hand, through a standardized policy configuration framework (including parameters such as fast restart count, interval policy, and self-check / self-healing program path), businesses can achieve fine-grained customization of restart policies without developing complex controllers, solving the problem of insufficient flexibility of native policies; on the other hand, the self-checking program (detecting node configuration, device status, etc.) and the self-healing program (performing repair based on standardized output conclusions) are integrated into the Kubelet execution flow, avoiding the limitations of traditional Operator solutions in cluster event monitoring, and can directly perform hardware-level self-checks and repairs on faulty nodes, significantly improving fault location efficiency and self-healing success rate.

[0051] A third embodiment of the present invention provides a container restart and self-healing system, comprising: One or more processors; Computer-readable storage medium for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method according to any one of claims 1 to 7.

[0052] A fourth embodiment of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

[0053] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or parts not listed in the claims. The words "a" or "an" preceding a component do not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. The use of the terms first, second, third, etc., is for convenience only and does not indicate any order. These terms can be understood as part of the component names.

[0054] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0055] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0056] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A method for optimizing thread communication in a microkernel operating system, characterized in that, include: S100: Responding to the event that the thread's request for communication resources is not satisfied, perform resource blocking processing, and set the blocking mode according to the resource type. The blocking mode includes non-waiting blocking, finite-time blocking, or permanent blocking. S200: For finite-time blocking mode, the current thread is attached to the system clock queue and a timeout is enabled; S300: Add the current thread to the resource blocking queue of the target resource; S400: Sets the thread to a blocked state and triggers the thread scheduler to schedule other ready threads; S500: In response to a resource fulfillment event, locate the blocking waiting queue of the target resource; S600: Perform wake-up processing on the first thread of the blocked waiting queue; S700: Add the woken-up thread to the thread's ready queue and switch it to the ready state.

2. The method according to claim 1, characterized in that: In S100, when the blocking mode is the non-waiting blocking mode, the error state is returned immediately; When the blocking mode is a permanent blocking mode, skip S200 and execute S300; S200 is only executed in the finite-time blocking mode.

3. The method according to claim 1, characterized in that: The S400 also includes: S410: Records the identifier and type of the blocked resource; S420: Store the random code generated by the resource management block when the resource is created to the thread control module.

4. The method according to claim 3, characterized in that: The S600 also includes: S610: Verify the consistency between the current random code of the resource management block and the random code stored in the thread control module. If the verification fails, terminate the wake-up process.

5. The method according to claim 3 or 4, characterized in that: The random code is generated in the following ways: Call the kernel security service to generate random numbers; Perform a hash operation or message authentication code algorithm on the random number and the physical address of the resource to generate a random code.

6. The method according to claim 4, characterized in that: When the verification fails in S610: Generate a log of unauthorized resource access; Returns a status indicating that the resource has been destroyed to the thread; Skip subsequent wake-up steps.

7. The method according to claim 1, characterized in that: The S600 also includes: S620: If a timeout occurs, remove the thread from the system clock queue; S630: Remove the thread from the resource blocking queue; S640: Set the wake-up reason flag and synchronize it to the thread control module.

8. A microkernel operating system thread communication optimization device, characterized in that, include: Resource management module: Responds to thread resource unmet events and performs resource blocking handling; Alternatively, it may respond to a thread resource fulfillment event and perform resource wake-up processing; Blocking processing module: Responds to resource blocking processing requests, sets the blocking mode according to the resource type, the blocking mode includes no-wait blocking, finite-time blocking or permanent blocking, and hangs the finite-time blocking thread in the system clock queue and the resource blocking queue. Thread control module: In response to the blocking result, set the current thread to the blocked state and trigger the thread scheduler to schedule other ready threads; or in response to the thread wake-up result, add the woken-up thread to the thread's ready queue and switch it to the ready state. Thread wake-up module: Responds to resource wake-up requests and performs wake-up processing on the first thread in the blocked waiting queue.

9. A microkernel operating system thread communication optimization system, characterized in that, include: One or more processors; Computer-readable storage medium for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images