Shared resource access method, apparatus, device, medium, and product

Abstract

The application discloses a shared resource access method and device, equipment, medium and product, relates to the technical field of efficient concurrent control and resource management in a computer system, and adopts a hybrid structure combining a lock-free ring queue and a double-ended queue. A load prediction unit is used to analyze queue data and predict a load trend, and then the queue capacity and a migration threshold are dynamically adjusted. The lock-free ring queue is preferentially used in daily use to improve access efficiency. When the queue approaches the upper limit of the capacity or triggers the migration threshold, the migration and expansion of the waiting coroutine are automatically realized through the double-ended queue, which guarantees the processing performance under high concurrency and meets the dynamic capacity demand, finally solves the technical problems that the performance and capacity of a single queue are difficult to balance under a high concurrency scenario and the single queue cannot adapt to dynamic loads, and realizes efficient scheduling of shared resources in a coroutine environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of efficient concurrency control and resource management in computer systems, and particularly relates to a shared resource access method and device, equipment, medium and product. BACKGROUND

[0002] In the fields of computer systems, network services, embedded devices, etc., synchronous access of shared resources is a core requirement to ensure program correctness. As a kind of lightweight user-mode thread, coroutines are widely used in high-concurrency scenarios due to their small switching overhead and high resource utilization. However, the mutex lock or simple coroutine mutex lock in the related art does not adapt to the characteristics of coroutines, and mostly uses a single waiting queue. In high-concurrency scenarios, performance and capacity are difficult to balance, which ultimately leads to low efficiency of shared resource access and affects system stability. SUMMARY

[0003] The present application provides a shared resource access method, device, equipment, medium and product to at least solve the technical problem that the single queue in the related art is difficult to balance performance and capacity in a high-concurrency scenario, resulting in low efficiency of shared resource access and poor system stability.

[0004] The present application provides a shared resource access method, comprising the following steps: creating a hybrid queue, wherein the hybrid queue comprises at least two queues; when a new coroutine issues an access request for a shared resource, obtaining a current state of a mutex lock; if the current state is an occupied state, obtaining queue data of the hybrid queue, predicting a first load according to the queue data, and adjusting at least one of a queue capacity and a migration threshold of the hybrid queue according to the first load; adding the new coroutine to the hybrid queue, performing migration of waiting coroutines between different queues in the hybrid queue based on the migration threshold, and selecting a waiting coroutine in the hybrid queue to access the shared resource.

[0005] The present application also provides a shared resource access device, comprising: a creating module configured to create a hybrid queue, wherein the hybrid queue comprises at least two queues; an obtaining module configured to, when a new coroutine issues an access request for a shared resource, obtain a current state of a mutex lock; an adjusting module configured to, if the current state is an occupied state, obtain queue data of the hybrid queue, predict a first load according to the queue data, and adjust at least one of a queue capacity and a migration threshold of the hybrid queue according to the first load; and an access module configured to add the new coroutine to the hybrid queue, perform migration of waiting coroutines between different queues in the hybrid queue based on the migration threshold, and select a waiting coroutine in the hybrid queue to access the shared resource.

[0006] The present application also provides an electronic device, comprising: a memory configured to store a computer program; and a processor configured to execute the computer program to implement the steps of the shared resource access method of the above-mentioned embodiments.

[0007] The application further provides a non-volatile computer readable storage medium, and the non-volatile computer readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the steps of the shared resource access method of the above-mentioned embodiments.

[0008] The application further provides a computer program product, comprising a computer program, which is executed by a processor to implement the steps of the shared resource access method of the above-mentioned embodiments.

[0009] Through the application, since the hybrid queue structure comprising at least two queues is adopted, the characteristics of different queues can be combined, and the system pressure is perceived in real time through load prediction, and the queue capacity and the migration threshold are dynamically adjusted accordingly, and the waiting coroutine is flexibly distributed among different queues based on the migration threshold, thereby breaking through the inherent contradiction between performance and capacity of a single queue, and being adaptive to dynamic load changes, so that the technical problem that the performance and capacity of a single queue are difficult to balance in a high concurrency scenario and cannot adapt to dynamic load in the related art can be solved, and the technical effects of improving the shared resource access efficiency in the coroutine environment, enhancing the adaptability of the system to dynamic load, and guaranteeing the stability of the system in a high concurrency scenario can be achieved. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0011] Figure 1 A flowchart of a shared resource access method provided for the embodiments of the application;

[0012] Figure 2 A hybrid waiting queue operation flowchart provided for the embodiments of the application;

[0013] Figure 3 A double wake-up mechanism flowchart provided for the embodiments of the application;

[0014] Figure 4 A biological heuristic timeout management flowchart provided for the embodiments of the application;

[0015] Figure 5 A blockchain operation log recording flowchart provided for the first embodiment of the application;

[0016] Figure 6 A blockchain operation log recording flowchart provided for the second embodiment of the application;

[0017] Figure 7A blockchain operation log recording flowchart provided for a third embodiment of the present application;

[0018] Figure 8 A blockchain operation log recording flowchart provided for a fourth embodiment of the present application;

[0019] Figure 9 A blockchain operation log recording flowchart provided for five embodiments of the present application;

[0020] Figure 10 A blockchain operation log recording flowchart provided for a sixth embodiment of the present application;

[0021] Figure 11 A whole architecture diagram of a coroutine mutex provided for an embodiment of the present application;

[0022] Figure 12 An example diagram of a shared resource access device provided for an embodiment of the present application;

[0023] Figure 13 A structure diagram of an electronic device provided for an embodiment of the present application. DETAILED DESCRIPTION

[0024] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, any other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0025] It should be noted that, in the description of the present application, the terms “include”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0026] At present, in the fields of computer systems, network services, embedded devices and the like, synchronous access to shared resources is a requirement to ensure program correctness. As a lightweight user-mode thread with small switching overhead and high resource utilization, coroutines have been widely used in high-concurrency scenarios. However, the mutual exclusion lock scheme in related technologies does not fully adapt to the characteristics of coroutines, and there are many deficiencies. Among them, the problems of traditional mutual exclusion locks and simple coroutine mutual exclusion locks in the coroutine environment are as follows:

[0027] First, the waiting queue operation efficiency is low in a high-concurrency scenario, and lock contention leads to performance bottlenecks and cannot adapt to dynamic load.

[0028] Secondly, the wake-up mechanism is single, which is prone to repeated wake-up or wake-up loss, high conflict rate and insufficient fairness in extreme high concurrency, and also affects the consistency of coroutine state;

[0029] Thirdly, there is a lack of native and intelligent timeout management, and the interaction with the coroutine scheduler is redundant, which leads to response delay, and the fixed timeout time is prone to performance loss or blocking risk;

[0030] Fourthly, it is difficult to balance thread safety and coroutine safety, and there is a risk of resource leakage, and the security audit capability is insufficient;

[0031] Fifthly, the atomic operation does not fully utilize the hardware characteristics, and the performance still has room for improvement.

[0032] Specifically, in the related art, the mutex lock takes thread as the design core, uses a single waiting queue and relies on mutex protection, and under high concurrency, the lock contention is intense, which not only does not support coroutine-level direct scheduling (the coroutine waiting needs to be switched to thread-level blocking, wasting system resources), but also has problems such as separation of timeout mechanism and lock logic (prone to race conditions), no dynamic load adaptation capability, atomic operation not optimized for hardware characteristics, and lack of security audit function; while the simple coroutine mutex lock supports coroutine waiting, but is mostly based on a single lock-free queue or a traditional queue, which has limitations such as fixed capacity (complex expansion logic is needed when the queue is full, and the flexibility is insufficient), single wake-up mechanism (prone to repeated wake-up or wake-up loss, affecting the consistency of coroutine state), shallow integration with coroutine scheduler (after wake-up, multiple steps are needed to put the coroutine into a runnable state, leading to response delay), no intelligent scheduling and dynamic timeout management, etc. In addition, the related technical solutions also generally face common problems such as unstable performance under dynamic load, insufficient fairness of wake-up (high conflict rate in extreme high concurrency scenarios), difficulty in balancing thread safety and coroutine safety (risk of resource leakage), and non-traceable operations in sensitive scenarios. In summary, the mutex lock solution in the related art has obvious deficiencies in adapting to coroutine characteristics, ensuring high-concurrency synchronization efficiency, implementing dynamic load adaptation, and meeting the needs of security management, etc.

[0033] To solve the above problems, the embodiment of the present application proposes a high-efficiency mutual exclusion lock design method based on coroutines. Specifically, the waiting coroutines are managed through the hybrid structure of the lock-free ring queue and the double-ended queue, the double-wakeup mechanism of active wakeup and timeout cancellation is combined, and the probability wakeup algorithm inspired by quantum computing is introduced. The intelligent timeout management is achieved by integrating the biological heuristic timing task. The intermediate links are reduced through the scheduling optimization of coroutines. At the same time, the dynamic adaptability is improved by integrating the machine learning driven adaptive queue management. The safety is guaranteed by using the atomic operation combined with hardware acceleration and the hierarchical control of mutual exclusion lock. The blockchain technology is also introduced to enhance the security audit capability. Finally, through the integration of these hybrid queue structures, wakeup mechanisms, timing integration, scheduling optimization and cross-domain technologies, efficient, safe, flexible and intelligent synchronization control is achieved in the coroutine environment. In order to enable the person skilled in the art to better understand the present application scheme, the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0034] In combination with the specific application environment architecture or specific hardware architecture on which the execution of the shared resource access method depends, the specific application environment architecture or specific hardware architecture is described herein.

[0035] It should be noted that the shared resource access method of the present application depends on the architecture of the coroutine runtime environment and hardware acceleration adaptation, such as processor environment supporting atomic operation hardware instructions, runtime system supported by coroutine scheduler, etc. The efficient operation of coroutine mutual exclusion lock is achieved through the following software function modules: hybrid waiting queue management module: responsible for managing the hybrid structure of lock-free ring queue and double-ended queue, providing load prediction function; double-wakeup control module: maintaining two state flags of "active wakeup" and "timeout cancellation" for each waiting coroutine, and providing probability scheduling function; timing task integration module: built-in biological heuristic timing task management logic, realizing intelligent timeout control; coroutine scheduling optimization module: realizing direct management of coroutine state and efficient interaction with scheduler, and providing adaptive priority adjustment; memory isolation module: ensuring the safety of atomic operation through memory alignment and providing hardware instruction adaptation; safety control module: balancing the hierarchical control mechanism of thread safety and coroutine safety, and providing blockchain operation log; resource management module: realizing the strategy of delayed release and component independent release, and providing blockchain log archiving; hybrid scheduling strategy module: optimizing the priority and efficiency of wakeup operation.

[0036] Figure 1 A flowchart of a shared resource access method provided by the embodiment of the present application is shown in the figure.

[0037] As shown in Figure 1 , the shared resource access method comprises the following steps:

[0038] In step S101, a hybrid queue is created, wherein the hybrid queue includes at least two queues.

[0039] It can be understood that the embodiment of the present application creates a hybrid queue including at least two queues to realize efficient synchronization access of shared resources in the coroutine environment. Through the combination design of multiple queues, the deficiencies of the related art that the mutual exclusion lock relies on a single queue when waiting for a coroutine are solved. The single queue often cannot simultaneously consider the rapid processing demand in a high concurrency scenario and the capacity demand that changes dynamically, and different queues in the hybrid queue can assume different functions, such as some queues focusing on rapid response in a high concurrency scenario and some queues focusing on capacity expansion according to demand. The contradiction between performance and capacity of a single queue is avoided, and structural support is provided for subsequent adjustment of queue parameters based on load and flexible migration of a waiting coroutine among different queues, which helps subsequent processes to more smoothly adapt to the actual demand of coroutine access to shared resources, and thus improves the overall access efficiency.

[0040] Specifically, the system initialization stage creates a hybrid queue, and the mutual exclusion lock is used as a tool for customers to use on demand. When the application of the customer has shared resources to be protected, the customer can create a mutual exclusion lock by itself, and destroy it after use. If other scenarios need to protect shared resources again, a mutual exclusion lock can be created again.

[0041] It should be noted that the hybrid queue can include multiple queues, such as two queues or three queues, and in the embodiment of the present application, the hybrid queue can include a first queue and a second queue. The first queue adopts an atomic operation when called, and the atomic operation is accelerated based on hardware characteristics. The second queue adopts a mutual exclusion lock operation when called.

[0042] In the embodiment of the present application, the hybrid queue includes a first queue and a second queue. The first queue adopts an atomic operation when called, and the atomic operation is accelerated based on hardware characteristics. The second queue adopts a mutual exclusion lock operation when called.

[0043] It can be understood that the hybrid queue in the embodiment of the present application includes a first queue and a second queue. The first queue adopts an atomic operation when called, and the operation is accelerated based on hardware characteristics. The second queue adopts a mutual exclusion lock operation when called. Different synchronization mechanisms are adopted for different scene demands. The atomic operation itself has the characteristics of lightness and efficiency, and can better adapt to high concurrency and low latency access scenarios after being accelerated by hardware characteristics. The mutual exclusion lock operation has higher stability in complex synchronization requirements and can cope with more complex resource competition scenarios. The single synchronization mechanism is broken through in efficiency and adaptability, so that the hybrid queue can quickly respond to high-frequency and low-complexity access requests through the first queue, and stably process high-complexity synchronization requirements through the second queue, thereby balancing efficiency and stability in different scenarios and further improving the overall adaptation ability of shared resource access.

[0044] It should be noted that the atomic operation refers to one or a series of operations that cannot be interrupted, which will not be disturbed by other threads or coroutines during execution, and can guarantee the integrity and consistency of the operation. For the first queue of the hybrid queue (such as a lock-free ring queue, a ring data structure that can be accessed concurrently without a mutex, which guarantees data consistency through atomic operations and has high efficiency in high-concurrency scenarios), the atomic operation is optimized based on specific hardware features, such as adapting the TSX instruction set of the x86 architecture, the LDREX / STREX instruction sequence of the ARM architecture, or calling atomicCAS and other device-side atomic operation APIs for GPU / CUDA scenarios, to accelerate access to the first queue (such as queue element insertion, state marking, etc.), ensuring that the operation of the first queue can be efficiently and consistently completed in a lock-free environment under high-concurrency coroutine competition.

[0045] The mutex operation is a synchronization mechanism used to ensure that shared resources are accessed by only one thread or coroutine at the same time, preventing concurrent conflicts through the "lock-access resource-unlock" process. For the second queue of the hybrid queue (such as a double-ended queue protected by a mutex), the mutex operation is triggered only when the first queue cannot meet the demand (such as the first queue being full), and is used to protect the insertion and deletion operations of the second queue, avoiding data chaos caused by multiple coroutines / threads operating the second queue simultaneously, and only introducing lock overhead when necessary, balancing the safety of resource access and performance loss. The double-ended queue is a linear data structure that allows insertion and deletion operations at both ends, with good flexibility.

[0046] Specifically, as shown in Figure 2 , the lock-free ring queue (as an efficient access path for shared resources) with dynamic capacity adjustment is used as the first queue, and the double-ended queue (as a fallback access path for shared resources) protected by a mutex is used as the second queue. This process is guided by the hybrid waiting queue management module: the module initializes to create a lock-free ring queue with dynamically adjustable capacity and a double-ended queue protected by a mutex, corresponding to the definition of the first queue (using atomic operations, accelerated based on hardware features) and the second queue (using mutex operations) of the hybrid queue.

[0047] In the embodiments of the present application, after creating the hybrid queue, the following steps are included: determining whether the memory address meets the alignment requirements of the atomic operation according to the hardware features; determining the memory allocation method of the queue and the atomic state variable according to the alignment requirements; allocating memory space to the corresponding queue based on the memory allocation method, and isolating the memory spaces of different queues.

[0048] It can be understood that, after the mixed queue is created, the embodiments of the present application first determine that the memory address meets the alignment requirement of the atomic operation according to the hardware characteristics, then determine the memory allocation mode of the queue and the atomic state variable according to the alignment requirement, and finally allocate memory space for the corresponding queue based on the mode and isolate the memory spaces of different queues.

[0049] Specifically, the memory isolation module determines that the memory address meets the alignment requirement of the atomic operation according to the hardware characteristics, isolates the memory spaces of different queues, and supports the allocation of memory according to the alignment requirement and the isolation of queue spaces after the mixed queue is created. The queue memory management is deeply adapted to the hardware characteristics. The atomic operation has strict requirements for the alignment of memory addresses, and failure to meet the requirements may result in operation failure or performance loss. The alignment mode determined according to the hardware characteristics can guarantee the reliability of the atomic operation. At the same time, the isolation of the memory spaces of different queues can avoid memory interference (such as data overflow and access conflict) between queues. The stability (ensuring the effective execution of the atomic operation) and safety (preventing the mutual influence of the memory between queues) of the underlying operation of the mixed queue are improved, a reliable memory foundation is provided for the scheduling of the upper-layer coroutine and the access of shared resources, the characteristics of the hardware environment are further adapted, and the efficient operation of the overall process is guaranteed.

[0050] In step S102, when a new coroutine issues an access request for a shared resource, the current state of the mutex is obtained.

[0051] It can be understood that, when a new coroutine issues an access request for a shared resource, the embodiments of the present application first obtain the current state of the mutex, determine whether the shared resource is in an occupied state, avoid the new coroutine from entering the waiting process when the resource is idle, or directly initiating access without preparation when the resource is occupied, provide clear basis for subsequent processing, if the resource is idle, the coroutine can directly and efficiently access; if the resource is occupied, the coroutine is guided into the mixed queue according to the rules, which reduces unnecessary queue operation overhead and avoids resource conflicts caused by blind access, and makes the entire shared resource access process more targeted and orderly.

[0052] It should be noted that the coroutine is a lightweight execution unit in the user mode, which is scheduled by the program itself (rather than the operating system kernel). The switching is completely completed in the user mode without kernel intervention, and only the context of the user mode, such as the stack and local variables of the coroutine itself, needs to be saved / restored, so the switching overhead is low. Multiple coroutines can be cooperatively run in a single thread, and non-blocking concurrency is realized through active “yielding of execution right”, which has very small resource consumption; it is suitable for IO-intensive tasks such as network requests and file reading and writing, and can efficiently support high-concurrency logic in a single thread, avoiding additional overhead of thread switching.

[0053] In the embodiment of the present application, after obtaining the current state of the mutex, if the current state is an idle state, the mutex is allocated to the new coroutine; the shared resource is accessed by the new coroutine, and the mutex is released after the access is completed.

[0054] It can be understood that, in the embodiment of the present application, after obtaining the current state of the mutex, if the state is idle, the mutex is directly allocated to the new coroutine, and the mutex is released after the new coroutine accesses the shared resource. When the resource is available, the waiting queue process is skipped, and the coroutine directly acquires the resource, thereby avoiding unnecessary queue enqueueing, queuing and other operation overheads. At the same time, the design of releasing the lock in a timely manner after the access is completed ensures that other waiting coroutines can quickly perceive the idle state of the resource, thereby reducing the idle time of the resource. The situation that the resource may experience a redundant scheduling link whether the resource is idle or not is avoided, and the immediacy of resource access and the efficiency of the overall process are further improved, thereby fully exerting the advantages of light switching of coroutines.

[0055] Specifically, after identifying the shared resource access request of the new coroutine, the current state of the mutex is obtained, and the safety control module is used to ensure the safety of the operation: the module uses atomic operations and hardware acceleration technology to ensure the efficiency and consistency of the acquisition of the lock state through the core state, such as the holding state of the lock. If the lock state is “idle”, the mutex is allocated to the new coroutine, and the mutex is released after the access is completed. This atomic lock allocation / release process relies on the hardware acceleration atomic operation capability of the safety control module.

[0056] In step S103, if the current state is an occupied state, queue data of the hybrid queue is obtained, a first load is predicted according to the queue data, and at least one of the queue capacity and the migration threshold of the hybrid queue is adjusted according to the first load.

[0057] It can be understood that, in the embodiment of the present application, when the mutex is in an occupied state, the queue data of the hybrid queue is obtained, the first load is predicted according to the data, and finally at least one of the queue capacity and the migration threshold of the hybrid queue is adjusted according to the predicted load. Based on the actual queue data, the number of current waiting coroutines, the degree of queue congestion and other situations can be truly reflected through the queue data, and the system pressure change can be perceived in advance according to the predicted load. The adjustment of the queue capacity can avoid overflow of the queue due to sudden increase of the load, or waste of resources due to sudden decrease of the load, and the adjustment of the migration threshold can make the migration of subsequent coroutines between different queues more in line with the actual load demand.

[0058] Therefore, the problem that the related art cannot adapt to dynamic load is solved, the waiting blockage or resource waste caused by fixed parameters under high concurrency is reduced, the management of the hybrid queue is more in line with the actual scenario of accessing shared resources by coroutines, and the efficiency of the process is further ensured.

[0059] It should be noted that the first load is when the mutex is in the occupied state, the system predicts the load trend index of the hybrid queue and the associated shared resource access in the short term based on the current queue data of the hybrid queue, such as the number of waiting coroutines, the queue length, the coroutine waiting time, etc., through a lightweight machine learning model or a specific algorithm.

[0060] The load trend index is used to quantify the dynamic changes of the subsequent coroutine competition pressure and resource access demand intensity of the system, and provides a basis for parameter adjustment of the hybrid queue. The migration threshold is used to trigger the critical judgment value of the coroutine migration behavior between different sub-queues in the hybrid queue. When the first load of the hybrid queue reaches the threshold, the migration process of the coroutines between different sub-queues is started, for example, when the first queue has free and the load is lower than the migration threshold, the waiting coroutines in the second queue are migrated to the first queue; and the migration threshold is dynamically adjusted according to the predicted first load, to adapt to the dynamic load changes of the system, for example, the queue migration threshold of the hybrid waiting queue management module is 30% when the load is lower than 30%, triggering the migration of the double-ended queue coroutines to the lock-free ring queue. The specific value and implementation of the migration threshold are not limited in the present application.

[0061] In addition, when the hybrid queue includes a lock-free ring queue and a double-ended queue, the insertion logic of the hybrid waiting queue is: preferentially inserting the lock-free ring queue, and inserting the double-ended queue when the queue is full; when waking up, the load prediction unit predicts the short-term load change, and if the lock-free ring queue has free and meets the migration threshold, the coroutines in the double-ended queue are migrated to the ring queue.

[0062] In the embodiments of the present application, the future load of the system is predicted according to the queue data, the queue data is input into the pre-trained machine learning model, and the machine learning model outputs the future load of the system. The machine learning model is based on a lightweight ML model.

[0063] It can be understood that the embodiments of the present application need to complete the load prediction first, to provide decision basis for subsequent coroutine selection strategy, timeout time adjustment, etc. Taking the queue data as input ensures that the prediction result fits the actual running situation of the queue, avoiding making predictions that are out of touch with the actual business; limiting the lightweight ML model balances the prediction accuracy and system resource consumption, avoiding complex models occupying too many computing resources and affecting the efficiency of coroutine scheduling. Through accurate future load prediction, the subsequent coroutine selection, resource allocation, etc. can be adapted to the system state in advance, such as adjusting the coroutine priority in advance when the predicted load increases, reducing the efficiency loss caused by passive response; at the same time, the low resource consumption characteristics of the lightweight model adapt to the lightweight and efficient demand of the coroutine, further ensuring the smoothness of the entire shared resource access process.

[0064] It should be noted that the lightweight ML model refers to a machine learning model with small amount of calculation and low resource consumption, such as linear regression and decision tree, which is suitable for real-time prediction scenarios.

[0065] Specifically, as shown in Figure 2 If the mutex is in the "occupied state", the queue data of the hybrid queue is obtained, the first load is predicted, and the queue capacity / migration threshold is adjusted, which is realized by the "load prediction unit" of the hybrid waiting queue management module: the module "real-time collection of queue length, coroutine waiting time, wake-up frequency and other data, training of lightweight ML model for prediction of short-term load change", corresponding to "prediction of the first load according to the queue data". Then "based on the prediction result, the capacity of the lock-free ring queue is automatically adjusted, for example, temporarily expanded to 2048 in high load, and the queue migration threshold is dynamically modified (for example, the double-ended queue coroutine migration is triggered when the load is lower than 30%)", corresponding to "adjusting at least one of the queue capacity and the migration threshold of the hybrid queue according to the first load".

[0066] In step S104, the new coroutine is added to the hybrid queue, the migration of the waiting coroutine between different queues in the hybrid queue is performed based on the migration threshold, and the waiting coroutine in the hybrid queue is selected to access the shared resource.

[0067] It can be understood that after the new coroutine is added to the hybrid queue in the embodiment of the application, the migration of the waiting coroutine between different queues is performed based on the previously adjusted migration threshold, and the waiting coroutine is selected to access the shared resource. Through the migration mechanism, the waiting coroutine is reasonably distributed between different queues, avoiding scheduling delay caused by excessive congestion of a single queue; and the process of selecting the waiting coroutine to access the resource can quickly match the appropriate coroutine when the resource is released, reducing invalid waiting. Thus, the fixed waiting queue and the lack of scheduling flexibility are avoided, the management of the waiting coroutine is more in line with the actual load change, the overall processing efficiency is improved through the dynamic balance between queues, the order of resource access is guaranteed, the conflict risk in high-concurrency scenarios is reduced, and the characteristics of lightweight and dense coroutines are further adapted.

[0068] In the embodiment of the application, adding the new coroutine to the hybrid queue includes: identifying the idle space of the target queue of the hybrid queue; if the idle space is greater than a first space threshold, adding the new coroutine to the target queue; and if the idle space is less than or equal to the first space threshold, adding the new coroutine to other queues.

[0069] It can be understood that, in the embodiment of the application, when a new coroutine is added to the hybrid queue, the idle space of the target queue in the hybrid queue is first identified, and then it is determined whether the idle space is greater than the first space threshold; if yes, the new coroutine is added to the target queue, and if no, the new coroutine is added to other queues. Through the logic of "comparing the idle space with the first space threshold", the queue is matched for the new coroutine, which avoids the problem that the random addition of the new coroutine may cause excessive congestion of some queues and idle resources of some queues. The load distribution in the hybrid queue is more balanced, the characteristics of different queues (such as the first queue focusing on efficient processing and the second queue focusing on bottom-up bearing) are fully utilized, the flexibility and overall efficiency of the hybrid queue management waiting coroutine are further improved, and a more reasonable foundation is laid for subsequent coroutine migration and resource access scheduling.

[0070] It should be noted that the first space threshold is a critical value for determining whether the target queue (preferably the first queue, i.e., the lock-free ring queue; or the second queue, i.e., the double-ended queue protected by the mutex) has the space condition for receiving the new coroutine when the new coroutine is added to the hybrid queue. Only when the current idle space of the target queue is greater than the threshold, the new coroutine can be added to the target queue; if the idle space of the target queue is less than or equal to the threshold, the new coroutine will be guided to other queues, so as to ensure that the target queue still has reasonable space margin after receiving the new coroutine, avoid excessive congestion affecting the running efficiency, and at the same time conform to the design logic of "preferentially utilizing efficient queue resources".

[0071] Specifically, as shown in Figure 2 , when the new coroutine is added to the hybrid queue, the hybrid waiting queue management module performs the logic of preferentially inserting the lock-free ring queue, and if the ring queue is full, inserting the double-ended queue, which corresponds to the process of "checking whether the ring queue is full? If yes, inserting the double-ended queue, otherwise, inserting the ring queue" in Figure 2 .

[0072] In the embodiment of the application, the migration of the waiting coroutine between different queues in the hybrid queue is performed based on the migration threshold, including: obtaining the second load of the hybrid queue and the idle space of the target queue in the hybrid queue; if the load value of the second load is less than the migration threshold, and the idle space of the target queue is greater than the second space threshold, the waiting coroutine in other queues is migrated to the target queue.

[0073] It can be understood that in the execution of the migration of the waiting coroutine between different queues in the hybrid queue, the second load of the hybrid queue and the free space of the target queue are first acquired. If the load value of the second load is less than the migration threshold and the free space of the target queue is greater than the second space threshold, the waiting coroutine of the other queue is migrated to the target queue. Through the double judgment of the load value and the free space, the accurate triggering of the coroutine migration is realized, which not only avoids the efficiency loss caused by blind migration when the load is too high, but also prevents the congestion caused by migration when the target queue space is insufficient. The distribution of the waiting coroutine in the hybrid queue is more balanced, the idle resources of each queue are fully utilized, the situation of congestion in part of the queue and idling in part of the queue is avoided, and the adaptive ability of the hybrid queue to the dynamic load is further improved, which provides more reasonable queue state support for the subsequent efficient access of shared resources.

[0074] It should be noted that the second load is the actual load index of the hybrid queue as a whole which is acquired in real time before the execution of the coroutine migration between the hybrid queues, and is different from the first load used for adjusting the queue parameters in advance, such as the short-term predicted load. The second load is calculated according to the data such as "queue length, coroutine waiting time" mentioned before, and is used to quantify the current task pressure level of the queue as a clear basis for adjusting the capacity and triggering the migration. Only when the second load value is less than the migration threshold and the free space of the target queue is sufficient, the waiting coroutine of the other queue is migrated, so as to avoid the excessive pressure of the target queue after the migration. The second space threshold is a critical space amount which is preset and used to judge whether the target queue in the hybrid queue has sufficient free space to receive the migrated coroutine. Only when the free space of the target queue is greater than the threshold, the waiting coroutine of the other queue is allowed to be migrated to the target queue, so as to avoid the congestion of the target queue caused by insufficient space after the migration.

[0075] Specifically, as shown in Figure 2 "Migration of the waiting coroutine between different queues in the hybrid queue based on the migration threshold", corresponds to the "queue migration function" of the hybrid waiting queue management module: when the free space of the lock-free ring queue appears, and the load prediction unit determines that "the load is lower than the migration threshold (such as 30%)", the waiting coroutine in the double-ended queue is migrated to the ring queue, which is consistent with the logic of "triggering the coroutine migration when the ring queue is idle" in Figure 2 .

[0076] In the embodiment of the application, before acquiring the release signal of the mutex and the state identifier of the waiting coroutine, the timeout time and the waiting time of the waiting coroutine in the hybrid queue are also acquired. If the waiting time does not reach the timeout time, the state identifier is determined as the second identifier. If the waiting time reaches the timeout time, the state identifier is determined as the third identifier.

[0077] It can be understood that, before acquiring the release signal of the mutex and the state identifier of the waiting coroutine, the embodiment of the application will first acquire the timeout time and the actual waiting time of the waiting coroutine in the hybrid queue. If the waiting time does not reach the timeout time, the state identifier is set to the second identifier. If the timeout time is reached, the state identifier is set to the third identifier. The timeout state of the waiting coroutine is clearly distinguished through the state identifier, which provides a clear basis for subsequent wake-up operations based on the state identifier, avoids invalid wake-up of the coroutine that has timed out, and also ensures that the coroutine that has not timed out can be processed in time. Redundant operations caused by ambiguous states are reduced, the management of the waiting coroutine is more accurate, and the explicit timeout state provides support for the system to clean up invalid waiting coroutines and release resources in time, further improving the effectiveness of the shared resource access process and the resource utilization rate.

[0078] It should be noted that the timeout time is the maximum waiting time configured in advance for the waiting coroutine in the hybrid queue, the waiting time is the actual waiting time of the coroutine since it entered the hybrid queue, the second identifier is a state identifier determined when the waiting time of the waiting coroutine in the hybrid queue does not reach the preset timeout time, representing that the coroutine is in a normal waiting state and has not triggered timeout processing, and is used by the system to identify that it is still within the effective waiting period, and the third identifier is a state identifier determined for the coroutine when the waiting time reaches the timeout time, and is used to trigger subsequent timeout processing logic. The timing task represents a task that needs to be executed at a specified time point, and can be used to implement timeout control and other functions.

[0079] Specifically, as shown in Figure 4 , the steps of "acquiring the timeout time and the waiting time of the waiting coroutine, dynamically adjusting the timeout time, and processing the timeout coroutine" are dominated by the timing task integration module: the module "automatically registers the timing task and initially sets the timeout time when the coroutine enters the waiting state", which corresponds to "acquiring the timeout time and the waiting time of the waiting coroutine in the hybrid queue"; "dynamically adjusting the timeout time (lengthening in high load and shortening in low load) through real-time monitoring of the system load (such as CPU utilization, memory level, I / O delay) by the environmental pressure sensing unit", which corresponds to "adjusting the timeout time of the waiting coroutine in the hybrid queue according to the third load of the system"; "when timeout is triggered, calling the double wake-up control module to set the 'cancel' flag and waking up the coroutine; if the coroutine continuously times out (such as the number of timeout times ≥ 3 times), triggering the 'abnormal reflection mechanism' to wake up urgently and alarming", which matches the process of "monitoring CPU / memory / I / O pressure, dynamically adjusting timeout time, timeout triggering, judging the number of continuous timeouts, and triggering the abnormal reflection mechanism" in Figure 4 .

[0080] In the embodiment of the present application, before determining that the state identifier is the third identifier, the method further comprises: obtaining a timeout number of the waiting coroutine and a preset number threshold; if the timeout number is less than the number threshold, setting the state identifier as the third identifier; and if the timeout number is greater than or equal to the number threshold, performing at least one of the wake-up action and the alarm action on the waiting coroutine.

[0081] It can be understood that, before determining that the state identifier is the third identifier, the embodiment of the present application first obtains a timeout number of the waiting coroutine and a preset number threshold; if the timeout number is less than the threshold, the state identifier is set as the third identifier; and if the timeout number reaches or exceeds the threshold, at least one of the wake-up and alarm operations is performed on the coroutine. The limitation of judging only according to a single timeout state is broken, and hierarchical processing is realized through the cumulative statistics of the timeout number. The coroutine with occasional timeout is maintained with a regular timeout identifier, and the coroutine with frequent timeout is actively intervened. Occasional timeout coroutines can be avoided from being over-processed, and frequent timeout coroutines with abnormal conditions can be found and processed in time, reducing the long-term occupation of resources by invalid waiting. At the same time, the alarm action enhances the perception ability of the system to abnormal conditions, further improving the stability and maintainability of the shared resource access process.

[0082] It should be noted that the number threshold is a preset critical number for judging the frequency of timeout of the waiting coroutine, and the third identifier is set when the timeout number is less than the threshold, and the wake-up or alarm action is triggered when the timeout number is greater than or equal to the threshold.

[0083] In the embodiment of the present application, before determining that the state identifier is the third identifier, the method further comprises: identifying whether the timeout time of the waiting coroutine is extended; and if the timeout time of the waiting coroutine is extended, performing at least one of the wake-up action and the alarm action on the waiting coroutine.

[0084] It can be understood that, before determining that the state identifier is the third identifier, the embodiment of the present application first identifies whether the timeout time of the waiting coroutine is extended; and if the timeout time is extended, at least one of the wake-up action and the alarm action is performed on the coroutine. The special scene that the timeout time is actively extended but still times out is processed. The timeout time is extended to give the coroutine more waiting opportunities, and if the timeout still occurs, it often implies that there may be a deeper abnormality in the coroutine or the resource, such as long-term occupation of the resource, failure of the coroutine itself, etc. This kind of coroutine is avoided from being in invalid waiting for a longer time due to the extension of the timeout time, and the resource is released by actively waking up or the manual intervention is triggered in time by the alarm, which reduces the long-term idling of the resource and enhances the sensitivity of the system to potential abnormalities, further improving the fault tolerance and problem response efficiency of the shared resource access process.

[0085] In the embodiment of the present application, before the waiting coroutine in the mixed queue is selected to access the shared resource, the release signal of the mutual exclusion lock and the state identifier of the waiting coroutine are further obtained, and the waiting coroutine is awakened according to at least one of the release signal and the state identifier.

[0086] It can be understood that, in the embodiment of the present application, before the waiting coroutine in the mixed queue is selected to access the shared resource, the release signal of the mutual exclusion lock and the state identifier of the waiting coroutine are obtained, and the waiting coroutine is awakened according to at least one of the release signal and the state identifier. The awakening operation is associated with the actual release state of the resource (the release signal) and the ready state of the coroutine itself (the state identifier), avoiding invalid operations such as prematurely awakening the coroutine when the resource is not released or forcibly awakening the coroutine when the coroutine state is not ready. The awakened waiting coroutine can not only respond to the idle state of the resource in time, but also be in a ready state to access the resource immediately, reducing the invalid waiting or state adjustment overhead after awakening, making the process from awakening to accessing the resource more accurate and efficient, and further ensuring the continuity and stability of the shared resource access.

[0087] In the embodiment of the present application, before the waiting coroutine in the mixed queue is selected to access the shared resource, the third load of the system and the health state of the waiting coroutine are further obtained, and the timeout time of the waiting coroutine in the mixed queue is adjusted according to at least one of the third load and the health state.

[0088] It can be understood that, in the embodiment of the present application, before the waiting coroutine in the mixed queue is selected to access the shared resource, the third load of the system and the health state of the waiting coroutine are obtained, and the timeout time of the waiting coroutine is adjusted according to at least one of the third load and the health state. The limitation of fixed timeout time in the related technical solution is broken through, so that the timeout setting can dynamically adapt to the actual running state of the system. When the system load is high, the timeout time can be appropriately prolonged to reduce the resource waste caused by frequent coroutine exits, and when the coroutine health state is poor, the timeout time can be shortened to avoid invalid waiting. The risk of coroutine blocking or resource idling caused by unreasonable timeout setting is reduced, the waiting mechanism is more suitable for the dynamic load of the system and the actual state of the coroutine, and the flexibility and reliability of the shared resource access process are further improved.

[0089] It should be noted that the third load is a system overall load index obtained before the waiting coroutine in the mixed queue is selected to access the shared resource, including CPU utilization, memory occupancy, etc., and is used to adjust the timeout time of the waiting coroutine in combination with the health state of the waiting coroutine to adapt to the current running pressure of the system.

[0090] In the embodiment of the present application, the waiting coroutine in the mixed queue is selected to access the shared resource, including: obtaining the queue priority and free space in the mixed queue; selecting a target queue in the mixed queue according to the queue priority and free space; calculating the selection weight of the waiting coroutine in the target queue according to the state data of the waiting coroutine; selecting the waiting coroutine from the target queue according to the selection weight, accessing the shared resource through the waiting coroutine, and releasing the mutex after the access is completed.

[0091] It can be understood that in the embodiment of the present application, when the waiting coroutine in the mixed queue is selected to access the shared resource, the priority and free space of each queue are first obtained, and the target queue is selected accordingly; then the selection weight is calculated according to the state data of the waiting coroutine in the target queue, and finally the coroutine is selected to access the resource according to the weight, and the mutex is released after the access is completed. Breakthrough the single mode of simple selection according to the order of entering the queue in the related technical solutions, through the combination of queue priority, free space and coroutine state data, the selection process is more suitable for the actual scene demand, which not only considers the overall state of the queue (such as high-priority queue is processed first), but also takes into account the individual differences of the waiting coroutine, such as the coroutine with more suitable state for fast execution is preferentially selected. Reducing the idle or inefficient access of resources caused by unreasonable selection, improving the accuracy and fairness of the allocation of shared resources, and at the same time, through the timely release of the lock after the access is completed, ensuring that other coroutines can quickly respond to the idle state of the resource, further enhancing the overall efficiency of the access to the shared resource in the high-concurrency scenario.

[0092] It should be noted that the quantum random walk theory is a random walk model that draws on the principles of quantum mechanics, which can be used to generate random sequences with a specific probability distribution.

[0093] Specifically, as shown in Figure 3 , the "selecting a waiting coroutine in a mixed queue to access a shared resource" is cooperatively completed by a double wake-up control module and a mixed scheduling strategy module: the mixed scheduling strategy module "preferentially processes the waiting coroutines in the lock-free ring queue, and reduces the dependence on the mutex of the double-ended queue", which corresponds to "selecting a target queue in the mixed queue according to the queue priority and free space (preferentially selecting the lock-free ring queue)"; the double wake-up control module "calculates a dynamic probability weight based on the state data (waiting time, coroutine priority, migration times, etc.) of the waiting coroutines in the target queue", which corresponds to "calculating the selection weight of the waiting coroutine in the target queue according to the state data of the waiting coroutine"; if the number of "woken-up waiting coroutines is greater than a preset number", the double wake-up control module realizes "probability algorithm screening of the target coroutine" through "probability conflict detection and secondary screening logic", which matches the process of "calculating the weight, quantum random walk algorithm calculating the probability, detecting the wake-up conflict, and secondary screening of the unique target" in Figure 3 .

[0094] In the embodiment of the present application, the selection weight of the waiting coroutine is calculated according to the state data of the target queue, including: identifying at least one of the waiting time, the wake-up frequency, the migration times and the coroutine priority of the waiting coroutine in the state data, and calculating the selection weight of the waiting coroutine according to at least one of the waiting time, the wake-up frequency, the migration times and the coroutine priority.

[0095] It can be understood that in the embodiment of the present application, at least one of the waiting time, the wake-up frequency, the migration times, the coroutine priority and the like of the waiting coroutine in the state data is identified when calculating the selection weight of the waiting coroutine, and the weight is calculated based on these information. Breakthrough the limitation of selecting the coroutine according to only a single dimension such as the order of entering in the related technical solutions, through the comprehensive consideration of multi-dimensional state data, the weight calculation is more suitable for the actual running state of the coroutine. For example, the coroutine with long waiting time can obtain higher weight to avoid starvation, and the coroutine with high priority can be selected preferentially to guarantee the efficiency of core tasks. The fairness and accuracy of coroutine selection are improved, which not only avoids the problem of long-term waiting of part of the coroutines, but also meets the resource demand of key coroutines preferentially, further optimizes the allocation efficiency of shared resources, and makes the overall scheduling more adaptive to the complex scenarios of coroutine environment.

[0096] In the embodiment of the present application, before the target coroutine accesses the shared resource, the state identifier of the target coroutine is set to a first identifier, and the target coroutine with the first identifier is obtained by the coroutine scheduler.

[0097] It can be understood that in the embodiment of the present application, before the target coroutine accesses the shared resource, the state identifier of the target coroutine is set to a first identifier, and the target coroutine with the first identifier is obtained by the coroutine scheduler. Through the exclusive state identifier, the waiting state of the target coroutine is determined, so that the coroutine scheduler can accurately identify and schedule, avoiding the misoperation or repeated scheduling of non-target coroutines in the scheduling process. The accuracy of coroutine scheduling is improved, the invalid overhead of the scheduling link is reduced, and through the cooperation of the state identifier and the scheduler, the switching from waiting to accessing of the target coroutine is smoother, further adapting the characteristics of coroutine lightweight scheduling, and ensuring the orderliness and efficiency of the shared resource access process.

[0098] Specifically, the first coroutine is the target coroutine whose state identifier is set to the first identifier, and the identifier is set before the target coroutine accesses the shared resource. The first identifier represents that the target coroutine has an effective state of being scheduled to access the shared resource, and will be identified and obtained by the coroutine scheduler to ensure the orderly access to the shared resource.

[0099] In the embodiment of the present application, when the waiting coroutine accesses the shared resource, the waiting coroutine is awakened, and the number of awakened waiting coroutines is obtained. If the number of awakened waiting coroutines is greater than a preset number, a target coroutine is selected from the waiting coroutines by a probability algorithm, and the shared resource is accessed by the target coroutine.

[0100] It can be understood that, in the embodiment of the present application, when the waiting coroutine accesses the shared resource, the waiting coroutine is awakened first, and the number of awakened waiting coroutines is obtained. If the number of awakened waiting coroutines exceeds a preset number, a target coroutine is selected by a probability algorithm to access the resource. When a large number of coroutines are awakened at the same time, conflicts and efficiency loss caused by resource contention are avoided. In related technologies, resource competition may be intensified due to the awakening of too many coroutines, while the probability algorithm can orderly select a suitable target coroutine, balancing the efficiency and fairness of resource allocation. The invalid competition in the high-concurrency awakening scenario is reduced, making the resource access process more orderly. At the same time, the algorithm is selected to adapt to the characteristics of coroutine intensive awakening, further improving the stability and overall efficiency of shared resource access.

[0101] It should be noted that the probability algorithm refers to an algorithm for selecting a target coroutine when the number of awakened waiting coroutines is greater than a preset number. The algorithm assigns dynamic probability weights to each waiting coroutine (possibly in combination with waiting time, priority, and other attributes), randomly selects a target coroutine according to probability, balances the fairness of resource access, and avoids efficiency loss caused by a large number of coroutines competing at the same time. The specific type and implementation of the probability algorithm is not limited in the present application.

[0102] By way of example, the probability weight calculation method takes the waiting time of the waiting coroutine, the coroutine priority, the historical awakening frequency, and the cumulative migration number as the core state data. Real-time data is collected by a load prediction unit and an environmental stress perception unit, and the original data is linearly mapped or quantized to 0-10 points according to business rules to eliminate index magnitude differences. Based on the need to balance fairness and efficiency, weights are assigned to the quantized indicators (0.4 for coroutine priority, 0.3 for waiting time, 0.2 for historical awakening frequency, and 0.1 for cumulative migration number). The selection weight is calculated using weighted summation, and then converted to a probability weight by "selection weight / total selection weight", which conforms to the dynamic allocation logic inspired by quantum random walk theory. The probability weight is used for coroutine awakening selection when the lock is released. If there is a conflict, the probability weight is recalculated based on the latest state data of the conflicting coroutines for secondary selection, ensuring that only one target is awakened, avoiding coroutine state abnormalities, and adapting to the efficient and fair needs in high-concurrency scenarios.

[0103] In the embodiment of the present application, after selecting a waiting coroutine in the hybrid queue to access the shared resource, the waiting coroutine in the hybrid queue is awakened when the mutex lock is destroyed, and the resources in the hybrid queue are released in turn, and the log data is recorded by the blockchain.

[0104] It can be understood that, after the application embodiment selects the waiting coroutine in the mixed queue to access the shared resource, when the mutex is destroyed, the coroutines still waiting in the mixed queue are woken up, and the resources of the mixed queue are released in turn, while the relevant log data is recorded through the blockchain. By waking up the waiting coroutine, the risk of the coroutine being permanently blocked due to lock destruction is avoided; by releasing the resources in turn, the leakage of resources such as memory and handle related to the mixed queue is prevented, and the effective recovery of system resources is ensured; and the non-tamperable feature of the blockchain is used to record the log, ensuring the traceability and data authenticity of key operations such as lock destruction and resource release, providing a reliable basis for subsequent problem troubleshooting and system audit. The robustness of the system in the resource recovery phase is improved, the long-term impact of the remaining resources on the system performance is avoided, and the transparency and security of the operation are enhanced through the blockchain log, further improving the reliability guarantee of the whole process of shared resource access.

[0105] It should be noted that the hash chain structure is a chain structure formed by concatenating hash values, and has a non-tamperable feature, which is commonly used for data integrity verification.

[0106] Specifically, as shown in Figure 5 , "waking up the remaining coroutines, releasing resources, and recording log data through the blockchain when the mutex is destroyed" is completed by the security control module and the resource management module: the resource management module "destroys the mutex, checks whether there are remaining waiting coroutines in the mixed queue, sets the 'cancel' flag and wakes up if there are, and then releases the resources such as the ring queue, the double-ended queue, and the timer task manager in turn", corresponding to "waking up the waiting coroutines in the mixed queue and releasing the resources in the mixed queue in turn when the mutex is destroyed"; the "operation log chain unit of the security control module records key operations such as lock acquisition, release, and timeout cancellation as a blockchain transaction (uses a hash chain structure to ensure non-tamperability)", and the "resource management module archives the blockchain log when it is destroyed, supporting post-compliance verification and security audit", are consistent with the process of "key operations triggering blockchain recording and log archiving" in Figure 5 .

[0107] According to the shared resource access method proposed in the application, a mixed queue containing at least two queues is created, when a new coroutine's shared resource access request is identified, the current state of the mutex is first acquired; if the resource is in an occupied state, the load is predicted through the mixed queue data, the queue capacity or the migration threshold is adjusted accordingly, the new coroutine is then added to the queue, the waiting coroutine is migrated across queues based on the migration threshold, and the waiting coroutine in the queue is selected to access the resource. Break through the limitations of single queue in performance and capacity, adapt to dynamic load changes, reduce lock contention under high concurrency, effectively improve the access efficiency and scheduling flexibility of shared resources in the coroutine environment.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the shared resource access method according to the above embodiments can be implemented by means of software on a general hardware platform as necessary, and of course can also be implemented by hardware, but in many cases the former is a better embodiment.

[0109] Next, the mixed waiting queue operation process will be described in detail through a specific embodiment. The mixed waiting queue management module is used to manage the waiting coroutine through the mixed structure of the lock-free ring queue and the double-ended queue. The waiting coroutine is preferentially inserted into the lock-free ring queue, and the double-ended queue is inserted when the queue is full. The mixed waiting queue management module includes a load prediction unit, which is used to collect data such as queue length, coroutine waiting time, and wake-up frequency in real time, train a lightweight ML model to predict short-term load changes, and dynamically adjust the capacity of the lock-free ring queue and the queue migration threshold based on the prediction results. As shown in Figure 2 the specific steps are as follows:

[0110] In step one, the mixed waiting queue is initialized: when the system starts, the mixed waiting queue management module performs initialization operation, creates a lock-free ring queue (efficient path) with dynamically adjustable capacity and a double-ended queue (bottom path) protected by a mutex, and initializes the "load prediction unit" to load the lightweight ML model (such as linear regression model) to provide a basis for subsequent load trend prediction.

[0111] In step two, the coroutine requests the queue and judges the lock state: when the coroutine initiates a shared resource access request, it first judges whether the mutex is idle; if the lock is idle, the coroutine directly acquires the lock and accesses the resource, and releases the lock after completion (corresponding to the "lock idle?", "acquire lock", and "release lock" processes in the figure); if the lock is in the occupied state, the processing flow of the waiting queue is entered.

[0112] In step three, load data collection and queue selection: if the lock is occupied, the load prediction unit collects load data of the mixed queue in real time (including queue length, coroutine waiting time, wake-up frequency, etc. of the lock-free ring queue and the double-ended queue), and inputs these data into the lightweight ML model to predict the load trend of the system in the short term; then it is judged whether the lock-free ring queue is full: if not, the waiting coroutine is inserted into the lock-free ring queue through atomic operation (efficient path); if it is full, the coroutine is inserted into the double-ended queue after locking (bottom path).

[0113] In step four, the timeout dynamic adjustment of the timing task registration: after the coroutine is enqueued, the timing task integration module registers a timeout task for it; at the same time, combined with the system load (such as CPU utilization, memory occupation, etc.) monitored by the "environmental stress perception unit", if it is determined to be a high-load scenario, the timeout time of the coroutine is extended; if it is a low-load scenario, the timeout time is shortened, realizing dynamic timeout adjustment.

[0114] In step five, the trigger and execution of queue migration: when the lock-free ring queue has idle space due to the release of the lock by the coroutine, and the load prediction unit predicts that the load is stable in the short term (e.g., the load is below the migration threshold of 30%) based on the lightweight ML model, the hybrid waiting queue management module triggers the queue migration function to migrate the waiting coroutines in the double-ended queue to the lock-free ring queue, reducing the subsequent dependence on the mutex lock of the double-ended queue and improving overall efficiency.

[0115] Through the above process, the hybrid waiting queue management module realizes "hierarchical cooperative scheduling of lock-free ring queues and double-ended queues, dynamic capacity adjustment and migration threshold optimization driven by load prediction, intelligent timeout adaptation in high / low load scenarios, and on-demand triggered coroutine cross-queue migration", which not only guarantees performance in high-concurrency scenarios with the help of lock-free structure, but also balances lock contention and resource scheduling fairness through double-ended queue bottoming and load prediction mechanism, providing efficient and flexible waiting queue management capabilities for coroutine mutexes.

[0116] Next, a specific embodiment will be used to describe the dual wake-up mechanism process in detail. The dual wake-up control module is used to maintain "active wake-up" and "timeout cancellation" state flags for each waiting coroutine, and the flag state is controlled through atomic operations to avoid repeated wake-up. The dual wake-up control module includes a probability scheduling unit that assigns a dynamic probability weight based on waiting time and coroutine priority to the waiting coroutine by drawing on the theory of quantum random walk, selects a wake-up object according to the probability weight, and performs secondary screening of the unique target through a probability algorithm when detecting a wake-up conflict, as shown in the following figure: Figure 3 The specific steps are as follows:

[0117] In step one, the lock release event trigger and coroutine state flag check: when the mutex lock release event occurs, the dual wake-up control module first checks the state flags of the waiting coroutines (the module maintains two state flags "active wake-up" and "timeout cancellation" for each waiting coroutine); if the coroutine state flag is "not awakened", the normal wake-up process is entered; if the state flag is "timeout cancellation" (i.e., the flag set by the timer task when the timeout occurs), the timeout processing is performed (return an error code and clean up resources, matching the logic of "forcibly awakening the coroutine and cleaning up the state when the timeout cancellation occurs"); if it is neither "not awakened" nor "timeout cancellation", a state exception alarm is triggered (the flag check avoids repeated wake-up and prevents race conditions).

[0118] In step two, queue selection and weight calculation of the probability scheduling unit: after confirming that the coroutine state is "not awakened", select the target queue to be awakened (preferentially select the lock-free ring queue, and select the double-ended queue if the ring queue is empty); then, the "probability scheduling unit" of the dual-wakeup control module assigns dynamic probability weights to the waiting coroutines in the corresponding queue based on the theory of quantum random walk (matching the logic of "assigning weights based on waiting time, coroutine priority, etc. by borrowing the theory of quantum random walk"):

[0119] If the lock-free ring queue is selected, the weight calculation factor is "waiting time x 0.6 + coroutine priority x 0.4";

[0120] If the double-ended queue is selected, the weight calculation factor is "waiting time x 0.5 + coroutine priority x 0.3 + migration times x 0.2" (through multi-dimensional factor calculation, avoid the "starvation" problem caused by single sequential awakening, and give long-term waiting low-priority coroutines a chance to be awakened).

[0121] In step three, probability selection based on quantum random walk and conflict detection: the probability scheduling unit of the dual-wakeup control module assigns a probability of being awakened to each coroutine according to the "quantum random walk algorithm" based on the calculated weights of each coroutine; then, it detects whether there is a conflict (i.e., the scenario where "multiple coroutine awakening conditions are met simultaneously"); if there is a conflict, it resolves the conflict through the logic of "secondary screening + exponential backoff" (matching the design of the "probability conflict detection" module) to determine a unique target coroutine (ensuring that only a single coroutine is awakened to avoid resource competition chaos).

[0122] In step four, atomic operation to set the "awakened" flag and timeout task cancellation: after determining the target coroutine, set its state flag to "awakened" through atomic operation (matching the logic of "setting the 'awakened' flag through atomic operation when actively awakening"), and call the timing task integration module to cancel the timeout task corresponding to the coroutine (if the coroutine is actively awakened, avoid triggering the timeout cancellation logic, matching the design of "automatically canceling the corresponding timing task if the coroutine is normally awakened before the timeout"); prevent conflict between the timeout logic and the active awakening logic.

[0123] In step five, coroutine scheduling and blockchain operation log recording: set the state of the target coroutine from "waiting" to "runnable" and submit it to the coroutine scheduler for execution; finally, the "operation log chain unit" of the safety control module records this awakening operation (which belongs to the category of critical lock operations) as a blockchain transaction, using a hash chain structure to ensure its tamper resistance (matching the design of "providing an 'operation log chain unit' to record critical lock operations as a blockchain transaction"), ensuring that the operation is traceable.

[0124] Through the above process, the double wake-up control module realizes "active wake-up and double-flag precise control of timeout cancellation, quantum random walk inspired fair probability scheduling, unique target selection under conflict detection, and coordination with timing tasks and blockchains", which not only solves the "coroutine starvation" problem that may exist in the related art, but also avoids race conditions through atomic operations and flag checks, while the auditability of the wake-up operation is guaranteed through the blockchain, ultimately providing core wake-up decision and control capabilities for efficient, fair, and safe operation of coroutine mutexes.

[0125] Next, a specific embodiment will be used to describe the biological heuristic timeout management process in detail. The timing task integration module is used to register timeout tasks for the waiting coroutine, and after the timeout, the "timeout cancellation" flag is triggered and the coroutine is awakened. The timing task integration module includes an environmental stress perception unit for real-time monitoring of system load and coroutine health status, dynamic adjustment of timeout time based on the environmental stress index, and an abnormal reflex mechanism for triggering emergency awakening when detecting abnormal blocking of the coroutine. As shown in Figure 4 the specific steps are as follows:

[0126] It should be noted that the environmental stress index is an index calculated based on the comprehensive system load (such as CPU utilization, memory occupancy) and coroutine health status (such as waiting time, wake-up success rate), which is used to reflect the system running pressure.

[0127] In step one, the timing task registration and initial configuration of the waiting coroutine: when the coroutine enters the waiting state due to the occupation of shared resources, the timing task integration module automatically registers a timing task for it based on the "biological heuristic timing logic", sets the timeout time according to the coroutine type (such as high-priority business coroutine, ordinary background coroutine) (for example, the initial timeout of high-priority coroutine is 50ms, and the initial timeout of ordinary coroutine is 100ms), and records the initial health status of the coroutine (such as "wake-up success rate 100%" and "waiting times 0").

[0128] In step two, real-time monitoring of environmental stress and index calculation: start the "environmental stress perception unit" to collect system load data (CPU utilization, memory occupancy, I / O queue length) and coroutine health data (current waiting time, historical wake-up success rate, recent migration times) in real time, and calculate the "environmental stress index" (range 0-100, the higher the value, the greater the pressure) through a weighted algorithm. For example: CPU utilization 80% corresponds to a stress value of 30, memory occupancy 90% corresponds to a stress value of 25, and coroutine wake-up success rate less than 50% corresponds to a stress value of 20, and the total stress index is 75.

[0129] In step three, dynamic adjustment of timeout time based on stress index: the timing task integration module adjusts the timeout time according to the calculated environmental stress index based on the "biological adaptability regulation" logic:

[0130] If the pressure index is ≤ 30 (low load): shorten the timeout time by 20% (e.g., from 100ms to 80ms) to speed up the response;

[0131] If 30 < pressure index ≤ 70 (medium load): keep the initial timeout time unchanged;

[0132] If the pressure index is > 70 (high load): extend the timeout time by 50% (e.g., from 100ms to 150ms) to avoid further overloading of the system due to frequent timeout processing.

[0133] After adjustment, the trigger time of the timing task is updated synchronously.

[0134] In step four, the state branch processing during the waiting process: during the coroutine waiting, two trigger conditions are detected in real time:

[0135] If the coroutine is normally awakened within the adjusted timeout time (e.g., receives the "wake up" flag from the double wake-up control module): the timing task integration module automatically cancels the timing task of the coroutine, avoiding the invalid execution of the timeout callback, and updates the coroutine health status (e.g., "wake up success rate + 1");

[0136] If it is still not awakened after the adjusted timeout time: trigger the timing task callback, the callback logic calls the double wake-up control module to set the "cancel" flag for the coroutine, and forcibly wakes up the coroutine, while recording "timeout times + 1".

[0137] In step five, the trigger and processing of the abnormal reflection mechanism: when the coroutine is awakened by timeout, the timing task integration module checks its cumulative timeout times:

[0138] If the cumulative timeout times < 3 times: only execute the regular timeout processing (e.g., the coroutine returns "timeout error" and reattempts or exits);

[0139] If the cumulative timeout times ≥ 3 times (judged as "abnormal blocking"): immediately trigger the "abnormal reflection mechanism", similar to the rapid stress response of organisms when encountering danger, on the one hand, forcibly wake up the coroutine and clean up the blocking state through the emergency interface, on the other hand, send alarm information (including coroutine ID, continuous timeout times, current system pressure index, etc.) to the system monitoring center, so that the operation and maintenance personnel can promptly troubleshoot lock contention exceptions.

[0140] Through the above process, the timing task integration module realizes the full-link biological heuristic management of "initial configuration, dynamic adaptation to the environment, intelligent processing of wake-up / timeout, and abnormal emergency response", which not only guarantees the flexibility of timeout control, but also improves the robustness of the system in responding to exceptions.

[0141] Next, the blockchain operation log recording process will be described in detail through a specific embodiment. The security control module is used to balance thread safety and coroutine safety. The security control module includes an operation log chain unit, which is used to record critical lock operations as blockchain transactions, and uses a hash chain structure to ensure tamper resistance. The resource management module is used to implement delayed release and component independent release. The resource management module is used to archive the blockchain log when destroying the mutex, supports post-compliance verification and security audit, and interfaces with the smart contract to implement contract-based lock policy management. As shown in Figures 5-10 , the specific steps are as follows:

[0142] It should be noted that steps two "atomic operation of core state and hardware acceleration synchronization" and step five "operation level distinction and double-ended queue operation log association" are logical layer actions, so they are not marked in the figure. Step two is the logic of achieving bottom layer synchronization through atomic operation and hardware acceleration technology when changing the lock holding state, queue count and other core state (providing a foundation for the consistency of subsequent log recording and lock operation). Step five is the classification recording logic of "thread level / coroutine level operation distinction" and "double-ended queue lock operation and log association" (ensuring that lock operations in different scenarios can be accurately and completely included in the blockchain log system). Both are key logical links that connect "operation triggering and recording" and "hash chaining and archiving".

[0143] In step one, as shown in Figure 5 , the system performs initialization operation log chain unit when starting, which specifically includes creating a hash chain structure, initializing a blockchain node connection, configuring an encryption algorithm, and building a basic framework for subsequent log recording. At the same time, when the system performs key lock operations such as "coroutine requests lock", "coroutine gets lock", "coroutine releases lock", "coroutine timeout cancels" (corresponding to the triggering actions of Figures 7-10 ), or "mutex destruction" (corresponding to the triggering actions of Figure 6 ), the event listener unit of the security control module captures the operation events in real time, extracts the operation type (such as request, get, release, timeout cancel, destroy), coroutine ID, lock identifier, operation timestamp and other core information.

[0144] In step two, if the operation involves changes to the holding state of the lock, the queue count and other core states, the security control module updates the state through atomic operation combined with hardware acceleration technology. For GPU / CUDA scenarios, device-side atomic operation API is called to accelerate the state synchronization of multi-coroutine competition for shared resources, ensuring consistency and high performance in a lock-free environment.

[0145] In step three, the security control module generates and stores operation records for different key lock operations:

[0146] As shown in Figure 7As shown, when a coroutine is canceled due to timeout, an operation record containing "coroutine ID, timeout time, operation type = cancel" is generated and stored in the operation data storage unit;

[0147] like Figure 8 As shown, when a coroutine requests a lock, it generates an operation record containing "coroutine ID, timestamp, operation type = request" and stores it in the operation data storage unit.

[0148] like Figure 9 As shown, when a coroutine acquires a lock, it generates an operation record containing "coroutine ID, lock holding status, operation type = acquire" and stores it in the operation data storage unit.

[0149] like Figure 10 As shown, when a coroutine releases the lock, it generates an operation record containing "coroutine ID, timeout, operation type = release" and stores it in the operation data storage unit.

[0150] In step four, the "Operation Log Chain Unit" of the security control module calculates a hash value based on the operation record in step three, according to the rule of "previous hash value + current operation record" (such as using the SHA-256 algorithm). Then, it writes the content containing the operation information and hash value into the blockchain block and appends it to the end of the blockchain. Data reliability is ensured through multi-node consensus verification (this process covers...). Figures 7-10 The actions of "calculating hash value" and "writing to blockchain block" are included.

[0151] In step five, the security control module distinguishes between thread-level and coroutine-level operations, identifying the initiator of the operation during log recording: if it is an inter-thread interaction (such as multi-threaded lock contention), it is marked as a "thread-level operation," recording the thread ID, hardware acceleration type of the atomic operation, etc.; if it is intra-coroutine synchronization (such as lightweight synchronization of a coroutine waiting queue), it is marked as a "coroutine-level operation," recording the coroutine scheduling context, lightweight synchronization method, etc. Simultaneously, when a double-ended queue performs an insertion / deletion operation (requiring mutex lock protection to avoid conflicts), the security control module, after acquiring the mutex lock and completing the queue operation, synchronously generates a blockchain log containing information such as "queue operation type, changes in the number of coroutines, and mutex lock holding duration," ensuring that the necessary lock overhead operations are fully recorded.

[0152] In step six, as Figure 6As shown, when the mutex is triggered to be destroyed, the resource management module performs: checks whether there are remaining waiting coroutines in the hybrid queue, and if so, wakes up and marks them as "canceled" to avoid resource leakage; archives the blockchain log generated by the safety control module to support post-compliance verification (such as comparing the hash value integrity, outputting an audit report) and safety audit (the audit system verifies the operation trajectory through the audit interface); independently releases components such as the ring queue, double-ended queue, and timing task manager to ensure that the overall destruction process is not affected when a certain component is abnormal; for sensitive scenarios such as finance and government affairs, the smart contract is also connected to implement "only allow specific coroutines to access sensitive resources" and other contract-based lock strategy management.

[0153] Through the above process, the safety control module and the resource management module cooperatively implement "blockchain traceability of key operations, safe release of resources in the destruction phase, and intelligent contract management and control in sensitive scenarios", which not only provides tamper-proof full-link recording for lock operations with the help of blockchain technology, but also guarantees the robustness of system destruction through delayed release and independent release strategies of resource management, while meeting the compliance requirements of sensitive scenarios.

[0154] Next, the coroutine scheduling optimization module, the memory isolation module, and the hybrid scheduling strategy module will be described in detail through a specific embodiment.

[0155] The memory isolation module ensures that the memory address meets the alignment requirements of atomic operations (such as 64-byte alignment) by allocating aligned memory for the lock-free ring queue and atomic state variables, reducing performance loss caused by cache conflicts, isolating the memory space of different queues to avoid cache conflicts affecting atomic operation performance, and providing a "hardware instruction adaptation unit" to optimize the TSX instruction set of x86 architecture and the LDREX / STREX instruction sequence of ARM architecture, implementing transactional atomic operations and building a solid foundation for atomic operations and queue management at the hardware and memory levels.

[0156] On this basis, the hybrid scheduling strategy module optimizes the priority and efficiency of the wake-up operation, prioritizes processing waiting coroutines in the lock-free ring queue when the lock is released, reduces the dependence on the lock of the double-ended queue, and only accesses the double-ended queue when the ring queue is empty to minimize lock contention. The coroutine scheduling optimization module directly manages the coroutine state and efficiently interacts with the scheduler, and provides adaptive priority adjustment. When a coroutine is woken up, its state is directly set from "waiting" to "runnable" without intermediate state conversion. Runnable coroutines are submitted through the coroutine scheduler interface such as the scheduling queue to reduce context switching overhead. High-priority coroutines are woken up based on the prediction of the ML model to further improve the accuracy and efficiency of scheduling.

[0157] In summary, the working process of the coroutine mutex lock in the embodiment of the application is as follows:

[0158] When the system is initialized, a hybrid waiting queue (a lock-free ring queue and a double-ended queue), a load prediction model, a hardware instruction adaptation unit, a probability scheduling unit, an operation log chain unit, an environmental stress perception unit, and related resources (such as a timing task manager and an atomic state variable) are created to provide a basis for the operation of the coroutine mutex lock. When a coroutine requests to obtain a lock, if the lock is idle, the coroutine directly obtains the lock; if the lock is occupied, the coroutine is added to the hybrid waiting queue and suspended, and a timeout task of the fusion biological heuristic is registered. When the coroutine holding the lock is released, a double-wakeup mechanism combined with a probability wakeup algorithm is used to select a waiting coroutine from the hybrid waiting queue, and the selected waiting coroutine is directly set to a runnable state and executed by the coroutine scheduler, and the operation log chain unit records the related operations. If the waiting coroutine triggers a timeout, the timing task manager based on the environmental stress perception automatically cancels the waiting state of the waiting coroutine and wakes it up to avoid permanent blocking. When the mutex lock is destroyed, the remaining waiting coroutines are checked and processed, the blockchain log is archived, and the resources are completely released.

[0159] Next, the overall architecture of the coroutine mutex lock will be described through a specific embodiment. As shown in FIG. 1, taking the scenario of “high-concurrency coroutine access to a shared cache” as an example, the implementation process of the embodiment of the application is described as follows: Figure 11

[0160] The coroutine mutex lock of the application aims to solve the synchronization problem when multiple coroutines (such as coroutines A, B, C, and D) concurrently access a shared resource (such as a shared cache). The goal of all coroutines is to access the shared resource in an orderly manner to avoid conflicts. The overall architecture of the coroutine mutex lock of the application is divided into a core data layer, a state control layer, a coroutine interaction layer, a security guarantee layer, and a function extension layer, which work together from bottom to top to achieve efficient synchronization.

[0161] ​The core data layer is dominated by a hybrid waiting queue management module (including a lock-free ring queue "efficient path" and a double-ended queue "bottom path"), and integrates a load prediction unit (stores waiting coroutine information, and is a basic data carrier for the entire lock mechanism); when the system starts, coroutine mutual exclusion lock instances, hybrid waiting queues (the initial capacity of the lock-free ring queue "efficient path" is 1024, and the double-ended queue "bottom path" is initially empty), and the load prediction unit (including ML models such as linear regression) are initialized; when coroutine A requests access to a shared resource and the lock is idle, coroutine B, C, and D requested at the same time do not need to be queued and can directly enter the subsequent level, but after the load prediction unit collects current queue data in real time, predicts the "short-term load trend", and determines that the capacity of the lock-free ring queue does not need to be adjusted, B and C enter the lock-free ring queue that is not full, and D enters the double-ended queue; when coroutine A releases the lock, the hybrid waiting queue management module will also migrate D to the lock-free ring queue based on the prediction result of the load prediction unit that the load is stable in the short term.

[0162] The state control layer is cooperated by a double wake-up control module and a hybrid scheduling strategy module, and includes a double wake-up flag, an atomic state variable, and a probability scheduling unit (responsible for state management and wake-up selection of waiting coroutines, and ensures the accuracy and fairness of wake-up and cancellation operations); the atomic state variable atomically sets the lock state to "held" when coroutine A acquires the lock, and the probability scheduling unit (belonging to the double wake-up control module) assigns dynamic probability weights to B and C according to their waiting times (assuming that coroutine B has a shorter waiting time and a weight of 0.6, and coroutine C has a longer waiting time and a weight of 0.4), and preferentially wakes up B to ensure the response speed of "short waiting tasks" and avoid slowing down the overall system efficiency due to long queuing of simple and short tasks, which balances the responsiveness and task processing fairness of the system. When the timeout or system shutdown calls the destruction function, the double wake-up control module sets the "cancel" flag for C and D to avoid permanent blocking.

[0163] The coroutine interaction layer is realized by a coroutine scheduling optimization module, which integrates adaptive priority adjustment logic to reduce scheduling delay, sets the states of waiting B, C, and D to "waiting" and suspends them, and after B is woken up, the coroutine scheduling optimization module sets the state of B to "runnable" and submits it to the coroutine scheduler, so that coroutine B is scheduled and executed.

[0164] The security guarantee layer is cooperated by a security control module and a memory isolation module, and realizes functions by combining a hardware accelerated atomic operation, a level control of a mutex, and a blockchain operation log; when initialized, a hardware instruction adaptation unit, a security control resource (an atomic lock state, a mutex), an operation log chain unit, and a blockchain related component are prepared to ensure that the blockchain related component can record key operations; in the whole process (coroutine A takes a lock, coroutines B / C / D are queued, coroutine A releases the lock, coroutine B is awakened, coroutine C times out, and the system calls a destruction function), the operation log chain unit records key operations, and in the stage of the system calling the destruction function, the resource management module also archives the blockchain log to support subsequent compliance verification and security audit.

[0165] The function expansion layer is supported by a timing task integration module and a resource management module, integrates a biological heuristic timing task management, a resource cleaning logic, and an intelligent contract docking (provides intelligent timeout control, destruction guarantee, and sensitive scene support, and enhances the flexibility, robustness, and security of the lock); based on the biological heuristic timing task management logic, when the load is low (CPU utilization is 20%, which belongs to low load), the environment pressure perception unit registers a timeout task (timeout time is 50ms) for B, C, and D, when the system load suddenly rises to 80%, the environment pressure perception unit detects that the environment pressure index rises and dynamically adjusts the timeout time of the remaining waiting coroutine (such as coroutine C) to 200ms; if D continuously attempts to acquire the lock for three times and all times out, the "abnormal reflection mechanism" of the timing task integration module is triggered, coroutine D is automatically awakened in an emergency and an alarm is given, so that permanent blocking is avoided; when the system calls the destruction function, the resource management module releases the ring queue, the double-ended queue, the timing task manager and other resources in turn, and the resource management module archives the blockchain log. The five-layer architecture cooperates to realize efficient, safe, and flexible synchronization control in the coroutine environment.

[0166] In summary, the embodiments of the application have at least the following beneficial effects:

[0167] (1) Efficiently support high concurrency scenarios: a hybrid waiting queue structure combining a lock-free ring queue and a double-ended queue is adopted, and machine learning driven adaptive queue management is integrated, so that lock contention can be reduced when high concurrency coroutines compete; the adaptability of the hybrid queue in a dynamic load scenario is improved by 40%, and the operation efficiency is improved by more than 50% compared with related technologies.

[0168] (2) Realize reliable and fair wake-up mechanism: avoid repeated wake-up and wake-up loss through "active wake-up" and "timeout cancel" double wake-up flags, combined with quantum computing inspired probability wake-up algorithm (borrowing quantum random walk theory to distribute dynamic probability weight); 0 state abnormality rate in 100,000 concurrent wake-up tests, wake-up conflict rate reduced to below 0.1% in extreme scenarios, system fairness index improved by 20%, significantly better than related technology single wake-up mechanism.

[0169] (3) Intelligent timeout management capability: built-in fusion biological heuristic timing task integration logic, no need for external timer intervention, dynamically adjust timeout time based on system load (CPU utilization, memory occupation, etc.) and coroutine health state through environment pressure sensing unit; performance loss caused by fixed timeout value reduced by 30%, timeout response delay controlled within 1ms, system self-healing capability in abnormal scenarios improved by 50%, coroutine permanent blocking rate reduced to 0 in extreme cases, simplify coroutine timeout logic development.

[0170] (4) Achieve fast coroutine scheduling response: directly interact with coroutine scheduler, combined with adaptive priority adjustment (wake up high priority coroutine according to ML model prediction results), intermediate link between wake-up and scheduling reduced by 60%, coroutine response speed improved by 30%-40%.

[0171] (5) Balance safety and performance: combined with hierarchical use of hardware accelerated atomic operations and mutex locks, key atomic operation performance improved by 2-3 times, pipeline stall reduced by 50%, energy efficiency ratio improved by 30% in mobile / embedded and other resource constrained scenarios, while ensuring thread / coroutine safety, lock overhead reduced to 1 / 3 of traditional solutions; introduce blockchain technology to ensure that the operation log chain unit records cannot be tampered with transactions, operation traceability improved by 100% in distributed environments, meet financial level compliance requirements, security audit efficiency improved by 50% in sensitive scenarios.

[0172] (6) Guarantee robust resource management: adopt delay release and component independent release strategy, ring queue, double-ended queue, timing task manager and other components are independently released, resource leakage rate is 0 in extreme scenarios such as abnormal destruction, improve system stability.

[0173] Figure 12 The structure diagram of the shared resource access device provided by the embodiment of the application is shown as Figure 12 The shared resource access device 120 includes a creation module 1201, an acquisition module 1202, an adjustment module 1203, and an access module 1204.

[0174] The creating module 1201 is configured to create a hybrid queue, and the hybrid queue includes at least two queues; the obtaining module 1202 is configured to identify a current state of a mutex when a new coroutine sends an access request for a shared resource; the adjusting module 1203 is configured to, if the current state is an occupied state, obtain queue data of the hybrid queue, predict a first load according to the queue data, and adjust at least one of a queue capacity and a migration threshold of the hybrid queue according to the first load; and the access module 1204 is configured to add the new coroutine to the hybrid queue, perform migration of a waiting coroutine between different queues in the hybrid queue based on the migration threshold, and select the waiting coroutine in the hybrid queue to access the shared resource.

[0175] In the embodiment of the present application, the allocation module is further included, and after the current state of the mutex is obtained, if the current state is an idle state, the mutex is allocated to the new coroutine; the shared resource is accessed by the new coroutine, and the mutex is released after the access is completed.

[0176] In the embodiment of the present application, the access module 1204 is further configured to identify whether a target queue of the hybrid queue meets a preset condition; if the target queue meets the preset condition, the new coroutine is added to the target queue; and if the target queue does not meet the preset condition, the new coroutine is added to another queue.

[0177] In the embodiment of the present application, the access module 1204 is further configured to obtain a second load of the hybrid queue and a free space of a target queue in the hybrid queue; if a load value of the second load is less than the migration threshold, and the free space of the target queue is greater than a second space threshold, the waiting coroutine in the other queue is migrated to the target queue.

[0178] In the embodiment of the present application, the access module 1204 is further configured to obtain queue priorities and free spaces in the hybrid queue; select a target queue in the hybrid queue according to the queue priorities and the free spaces; calculate selection weights of the waiting coroutines according to state data of the waiting coroutines in the target queue; select the waiting coroutine from the target queue according to the selection weights, access the shared resource by the waiting coroutine, and release the mutex after the access is completed.

[0179] In the embodiment of the present application, the calculation module is further included, and is configured to calculate selection weights of the waiting coroutines according to state data of the waiting coroutines in the target queue, identify at least one of a waiting time, a wake-up frequency, a migration number and a coroutine priority of the waiting coroutine in the state data, and calculate the selection weights of the waiting coroutines according to the at least one of the waiting time, the wake-up frequency, the migration number and the coroutine priority.

[0180] In the embodiment of the present application, the waiting module is further included, which is configured to access the shared resource by the waiting coroutine, wake up the waiting coroutine, and acquire the number of the waiting coroutines that are woken up; if the number of the woken-up coroutines is greater than a preset number, the target coroutine is selected from the waiting coroutines by a probability algorithm, and the shared resource is accessed by the target coroutine.

[0181] In the embodiment of the present application, the setting module is further included, which is configured to set the state identifier of the target coroutine to the first identifier before the target coroutine accesses the shared resource; and the target coroutine with the first identifier is acquired by the coroutine scheduler.

[0182] In the embodiment of the present application, the first wake-up module is further included, which is configured to acquire the release signal of the mutex and the state identifier of the waiting coroutine before the waiting coroutine in the hybrid queue is selected to access the shared resource; and the waiting coroutine is woken up according to at least one of the release signal and the state identifier.

[0183] In the embodiment of the present application, the timeout adjustment module is further included, which is configured to acquire the third load of the system and the health state of the waiting coroutine before the waiting coroutine in the hybrid queue is selected to access the shared resource; and the timeout time of the waiting coroutine in the hybrid queue is adjusted according to at least one of the third load and the health state.

[0184] In the embodiment of the present application, the determining module is further included, which is configured to acquire the timeout time and the waiting time of the waiting coroutine in the hybrid queue before the release signal of the mutex and the state identifier of the waiting coroutine are acquired; if the waiting time does not reach the timeout time, the state identifier is determined as the second identifier; and if the waiting time reaches the timeout time, the state identifier is determined as the third identifier.

[0185] In the embodiment of the present application, the second wake-up module is further included, which is configured to acquire the timeout number of the waiting coroutine and a preset number threshold before the state identifier is determined as the third identifier; if the timeout number is less than the number threshold, the state identifier is set as the third identifier; and if the timeout number is greater than or equal to the number threshold, at least one of the wake-up action and the alarm action is performed on the waiting coroutine.

[0186] In the embodiment of the present application, the third wake-up module is further included, which is configured to identify whether the timeout time of the waiting coroutine is extended before the state identifier is determined as the third identifier; if the timeout time of the waiting coroutine is extended, at least one of the wake-up action and the alarm action is performed on the waiting coroutine.

[0187] In the embodiment of the present application, the isolation module is further included, which is configured to determine that the memory address meets the alignment requirement of the atomic operation according to the hardware feature after the hybrid queue is created; determine the memory allocation mode of the queue and the atomic state variable according to the alignment requirement; allocate the memory space to the corresponding queue based on the memory allocation mode, and isolate the memory spaces of different queues.

[0188] In the embodiment of the present application, the mixed queue includes a first queue and a second queue, the first queue adopts an atomic operation when being invoked, the atomic operation is accelerated based on hardware characteristics, and the second queue adopts a mutex operation when being invoked.

[0189] In the embodiment of the present application, the recording module is further included, which is configured to wake up the waiting coroutine in the mixed queue when the mutex is destroyed after the waiting coroutine in the mixed queue is selected to access the shared resource; and release the resources in the mixed queue in sequence, and record log data through a blockchain.

[0190] In the embodiment of the present application, the prediction module is further included, which is configured to predict a future load of the system according to queue data, input the queue data into a machine learning model pre-trained, and output the future load of the system by the machine learning model, the machine learning model being a lightweight ML model.

[0191] The features of the embodiment of the shared resource access device corresponding to the shared resource access method can be referred to the related description of the embodiment of the shared resource access method, which will not be repeated here.

[0192] The shared resource access device of the embodiment of the present application creates a mixed queue including at least two queues, acquires a current state of a mutex when identifying a shared resource access request of a new coroutine, adjusts a queue capacity or a migration threshold according to a predicted load of the mixed queue data if the resource is in an occupied state, adds the new coroutine into the queue, realizes migration of the waiting coroutine across queues based on the migration threshold, and selects the waiting coroutine in the queue to access the resource. The shared resource access device breaks through the limitation of a single queue in performance and capacity, adapts to dynamic load changes, reduces lock contention under high concurrency, and effectively improves the access efficiency and scheduling flexibility of the shared resource in the coroutine environment.

[0193] Figure 13 The structure schematic diagram of the electronic device provided in the embodiment of the present application is provided. The electronic device can include:

[0194] The memory 1301, the processor 1302, and the computer program stored in the memory 1301 and executable on the processor 1302.

[0195] The processor 1302 executes the program to implement the shared resource access method provided in the above embodiment.

[0196] Further, the electronic device further includes:

[0197] The communication interface 1303 is configured to communicate between the memory 1301 and the processor 1302.

[0198] The memory 1301 is configured to store the computer program executable on the processor 1302.

[0199] The memory 1301 can include a high-speed RAM (Random Access Memory) memory, and can also include a nonvolatile memory, such as at least one disk memory.

[0200] If the memory 1301, the processor 1302 and the communication interface 1303 are implemented independently, the communication interface 1303, the memory 1301 and the processor 1302 can be connected to each other through a bus and complete communication between each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For convenience of representation, Figure 13 Only one thick line is used in the figure to represent the bus, but it does not mean that there is only one bus or only one type of bus.

[0201] Optionally, in a specific implementation, if the memory 1301, the processor 1302 and the communication interface 1303 are integrated on a chip, the memory 1301, the processor 1302 and the communication interface 1303 can complete communication between each other through an internal interface.

[0202] The processor 1302 can be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement one or more embodiments of the present application.

[0203] The embodiments of the present application also provide a nonvolatile computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the shared resource access method according to the above embodiments.

[0204] In an example embodiment, the above-mentioned nonvolatile computer readable storage medium can include, but is not limited to, a U disk, a ROM (Read-Only Memory), a mobile hard disk, a magnetic disk, an optical disk, an SSD (Solid State Drive) and various media that can long-term store computer programs and do not lose data after power off.

[0205] Embodiments of the present application also provide a computer program product, which comprises a computer program, and the computer program, when executed by a processor, implements the steps in the method embodiments of the shared resource access method as described above.

[0206] Those skilled in the art will further appreciate that the functions of the examples described herein-based units and algorithm steps can be implemented using electronic hardware, computer software, or any combination thereof. When the functions are implemented in software, the functions can be stored on or transmitted over a computer-readable medium, such as an optical, magnetic or semiconductor storage medium. The order of execution or the arrangement of code or steps can be changed, or individual code or steps can be combined or broken apart, or additional code or steps can be added, without departing from the scope of the application. Thus, the functions described herein-based examples can be implemented using any number of hardware and software configurations.

[0207] The above provides a shared resource access method, device, equipment, medium and product. The principles and implementation manners of the present application are described by applying specific examples. The above description of the embodiments is only used to help understand the method and its core idea. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, some improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for accessing shared resources, characterized in that, Includes the following steps: Create a hybrid queue, wherein the hybrid queue includes at least two queues, the hybrid queue includes a first queue and a second queue, the first queue is invoked using atomic operations, the atomic operations are accelerated based on hardware characteristics, and the second queue is invoked using mutex lock operations; When a new coroutine issues an access request for shared resources, obtain the current state of the mutex lock; If the current state is occupied, then the queue data of the hybrid queue is obtained, a first load is predicted based on the queue data, and at least one of the queue capacity and migration threshold of the hybrid queue is adjusted based on the first load. The new coroutine is added to the hybrid queue, and the migration of waiting coroutines between different queues in the hybrid queue is performed based on the migration threshold. The waiting coroutine in the hybrid queue is selected to access the shared resource.

2. The shared resource access method according to claim 1, characterized in that, After obtaining the current state of the mutex, the following steps are also included: If the current state is an idle state, then the mutex lock is assigned to the new coroutine; The shared resource is accessed through the new coroutine, and the mutex is released after the access is completed.

3. The shared resource access method according to claim 1, characterized in that, Adding the new coroutine to the hybrid queue includes: Identify the free space of the target queue of the hybrid queue; If the free space is greater than the first space threshold, the new coroutine is added to the target queue; If the free space is less than or equal to the first space threshold, the new coroutine is added to another queue.

4. The shared resource access method according to claim 1, characterized in that, The migration of waiting coroutines between different queues in the hybrid queue based on the migration threshold includes: Obtain the second load of the hybrid queue and the free space of the target queue in the hybrid queue, wherein the second load is the real-time load of the hybrid queue; If the load value of the second load is less than the migration threshold, and the free space of the target queue is greater than the second space threshold, then the waiting coroutines in other queues will be migrated to the target queue.

5. The shared resource access method according to claim 1, characterized in that, The step of selecting waiting coroutines in the hybrid queue to access the shared resource includes: Obtain the queue priority and free space in the hybrid queue; The target queue in the hybrid queue is selected based on the queue priority and the free space. Calculate the selection weight of the waiting coroutine based on the status data of the waiting coroutines in the target queue; According to the selection weight, a waiting coroutine is selected from the target queue, accesses the shared resource through the waiting coroutine, and releases the mutex lock after the access is completed.

6. The shared resource access method according to claim 5, characterized in that, The step of calculating the selection weight of the waiting coroutine based on the status data of the waiting coroutines in the target queue includes: Identify at least one of the waiting time, wake-up frequency, migration count, and coroutine priority of the waiting coroutine in the state data, and calculate the selection weight of the waiting coroutine based on at least one of the waiting time, wake-up frequency, migration count, and coroutine priority.

7. The shared resource access method according to claim 5, characterized in that, The method of accessing the shared resource through the waiting coroutine also includes: Wake up the waiting coroutine and obtain the number of waiting coroutines that have been woken up; If the number of awakened coroutines is greater than a preset number, a target coroutine is selected from the waiting coroutines using a probability algorithm, and the shared resource is accessed through the target coroutine.

8. The shared resource access method according to claim 7, characterized in that, Before accessing the shared resource through the target coroutine, the following is included: Set the status flag of the target coroutine to the first flag; The target coroutine with the first identifier is obtained through the coroutine scheduler.

9. The shared resource access method according to claim 1, characterized in that, Before selecting a waiting coroutine in the hybrid queue to access the shared resource, the process also includes: Obtain the release signal of the mutex lock and the status flag of the waiting coroutine; The waiting coroutine is awakened based on at least one of the release signal and the status identifier.

10. The shared resource access method according to claim 1, characterized in that, Before selecting a waiting coroutine in the hybrid queue to access the shared resource, the process also includes: Obtain the third load of the system and the health status of the waiting coroutines, wherein the third load is the overall system load; adjust the timeout of the waiting coroutines in the hybrid queue based on at least one of the third load and the health status.

11. The shared resource access method according to claim 9 or 10, characterized in that, Before obtaining the release signal of the mutex and the status flag of the waiting coroutine, the process also includes: Obtain the timeout and waiting time of the waiting coroutines in the mixed queue; If the waiting time does not reach the timeout period, then the status identifier is determined to be the second identifier; If the waiting time reaches the timeout period, then the status identifier is determined to be the third identifier.

12. The shared resource access method according to claim 11, characterized in that, Before determining that the status identifier is a third identifier, the process also includes: Obtain the number of timeouts for the waiting coroutine and the preset threshold number of times; If the number of timeouts is less than the number threshold, then the status identifier is set to the third identifier; If the number of timeouts is greater than or equal to the number threshold, then at least one of the wake-up action and alarm action is performed on the waiting coroutine.

13. The shared resource access method according to claim 11, characterized in that, Before determining that the status identifier is a third identifier, the process also includes: Identify whether the timeout period for the waiting coroutine has been extended; If the timeout period of the waiting coroutine is extended, then at least one of the wake-up action and alarm action is performed on the waiting coroutine.

14. The shared resource access method according to claim 1, characterized in that, After creating the hybrid queue, the following is included: Based on hardware characteristics, the memory address is determined to meet the alignment requirements of atomic operations; The memory allocation method for the queue and atomic state variables is determined based on the alignment requirements. Memory space is allocated to the corresponding queues based on the memory allocation method, thus isolating the memory spaces of the different queues.

15. The shared resource access method according to claim 1, characterized in that, After selecting the waiting coroutines in the hybrid queue to access the shared resource, the process further includes: When the mutex is destroyed, the waiting coroutines in the hybrid queue are awakened; The resources in the hybrid queue are released sequentially, and log data is recorded via the blockchain.

16. A shared resource access device, characterized in that, include: A creation module is provided for creating a hybrid queue, wherein the hybrid queue includes at least two queues, namely a first queue and a second queue. When the first queue is invoked, an atomic operation is performed, which is accelerated based on hardware characteristics. When the second queue is invoked, a mutex lock operation is performed. The acquisition module is used to obtain the current state of the mutex lock when a new coroutine issues an access request for shared resources; An adjustment module is configured to, if the current state is an occupied state, obtain the queue data of the hybrid queue, predict a first load based on the queue data, and adjust at least one of the queue capacity and migration threshold of the hybrid queue based on the first load; The access module is used to add new coroutines to the hybrid queue, perform migration of waiting coroutines between different queues in the hybrid queue based on the migration threshold, and select waiting coroutines in the hybrid queue to access the shared resource.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the shared resource access method as described in any one of claims 1 to 15 when executing the computer program.

18. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the shared resource access method as described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the shared resource access method as described in any one of claims 1 to 15.

Images