Coroutine concurrency control method, electronic equipment, medium and product
By removing coroutines from the ready queue when coroutine lock fails and using event processors and auxiliary coroutines to control the lock users, the blocking problem caused by coroutine locking is solved, system performance and flexibility are improved, data inconsistency is avoided, and efficient coroutine locking in pure user mode is achieved.
Patent Information
- Application Number
- CN202510529292.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-25
- Publication Date
- 2025-07-25
AI Technical Summary
In the prior art, coroutine locking causes blocking, especially in lock competition scenarios, blocking during coroutine locking will cause thread blocking, affecting system performance, and blocking may also lead to blocking through file locking operations.
When a coroutine to be locked fails when a coroutine to be locked is detected, the coroutine to be locked is removed from the ready queue and the central processor is given up. The user of the locked coroutine is controlled by the event processor and/or auxiliary coroutine to control the lock to be locked coroutines, avoiding the blockage of the locked coroutines, and implementing the locking process through a pure user state to avoid the impact of system calls and kernel queues.
It effectively avoids blocking of locking coroutines, improves system performance, avoids data inconsistency problems, and improves the flexibility of the way to implement control locks, meeting the needs of pure user implementation.
Smart Images
Figure CN120371568A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular, to a coroutine concurrency control method, an electronic device, a medium, and a product. Background Art
[0002] With the sharp increase in the system's concurrent processing requirements, coroutines, as a lightweight concurrent programming model, are widely used. In a multi-coroutine running environment, locks are required for coroutine synchronization to ensure that at most one coroutine can access shared data to guarantee data consistency.
[0003] In related coroutine locking technical solutions, in a lock competition scenario, when the lock acquisition fails, the coroutine needs to enter the kernel waiting queue, and the kernel intervenes to determine the lock owner. The blocking wait during coroutine locking in this method will cause the blocking of the thread where the coroutine is located, thus blocking all coroutines on this thread; in addition, in related coroutine locking technical solutions, file locks are also used to ensure access mutual exclusion, but coroutines may be blocked due to file locking operations based on this method, affecting system performance.
[0004] Therefore, it can be seen that how to solve the problem of blocking caused by locking is a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention
[0005] The present invention provides a coroutine concurrency control method, an electronic device, a medium, and a product to at least solve the problems of coroutine blocking and blocking of the thread where the coroutine is located caused by locking in related technologies.
[0006] The present invention provides a coroutine concurrency control method, including:
[0007] When it is detected that the coroutine to be locked fails to acquire the lock, remove the coroutine to be locked from the ready queue and control the coroutine to be locked to yield the central processing unit; wherein, the coroutines in the ready queue are the coroutines to be executed by the scheduler;
[0008] Control the lock user to be the coroutine to be locked by using an event processor and / or by using an auxiliary coroutine created based on the coroutine to be locked; wherein, the event processor is used to process the lock acquisition request event or the event of cross-thread migration of the coroutine to be locked;
[0009] Move the coroutine to be locked into the ready queue so that the scheduler can control the coroutine to be locked to perform operations to access the shared resource area.
[0010] The beneficial effects of the present invention are as follows. First, in this method, when it is detected that the coroutine to be locked fails to lock, the coroutine to be locked is removed from the ready queue and the coroutine to be locked is controlled to yield the central processing unit, avoiding the blocking of the locking coroutine and the blocking on the thread where the locking coroutine is located. Second, after the coroutine to be locked yields the central processing unit, by using the event processor and / or the auxiliary coroutine created based on the coroutine to be locked, the user of the lock is controlled to be the coroutine to be locked, that is, it is realized that the coroutine to be locked can successfully lock. After successfully locking, the coroutine to be locked is moved into the ready queue. Under the control of the scheduler, the coroutine to be locked in the ready queue can perform the operation of accessing the shared resource area, avoiding the occurrence of the problem of data inconsistency when multiple coroutines access shared data at the same time. Third, when realizing that the user of the lock is the coroutine to be locked, it can be realized through the event processor, can be realized through the auxiliary coroutine created based on the coroutine to be locked, and can also be realized jointly by the event processor and the auxiliary coroutine created based on the coroutine to be locked, improving the flexibility of the method for realizing the control of the user of the lock to be the coroutine to be locked. In addition, in the case where the lock acquisition fails and it is necessary to enter the kernel waiting queue and the kernel intervenes to determine the lock owner, in the method provided by the present invention, the user of the lock is controlled to be the coroutine to be locked by using the event processor and / or the auxiliary coroutine created based on the coroutine to be locked, which is implemented in pure user mode. Therefore, there is no situation that the context switch from user mode to kernel mode initiated by the coroutine is very frequent and the kernel queue may be long, which will slow down the system performance as a whole and violate the disadvantage of the pure user-mode implementation of the coroutine. Moreover, compared with the method of using file locks, in the method provided by the present invention, no file is locked, avoiding the situation where the lock acquisition is blocked due to file locking operations and affecting the system performance.
[0011] The present invention also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above coroutine concurrency control methods when executing the computer program.
[0012] The present invention also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above coroutine concurrency control methods are implemented.
[0013] The present invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, the steps of any of the above coroutine concurrency control methods are implemented. Description of the Drawings
[0014] To more clearly illustrate the embodiments of the present invention, the following will briefly introduce the accompanying drawings required in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.
[0015] Figure 1 A schematic diagram of a scenario for handling lock contention through kernel intervention provided by an embodiment of the present invention;
[0016] Figure 2 A schematic diagram of a coroutine concurrency control method provided by an embodiment of the present invention;
[0017] Figure 3 A flowchart of a processing method for a scenario where a coroutine that has not released a lock and a coroutine that requests a lock are not on the same thread and the lock acquisition fails, provided by an embodiment of the present invention;
[0018] Figure 4 A flowchart of a processing method for a lock acquisition scenario where a coroutine that defines a lock and a coroutine to be locked are on the same thread, provided by an embodiment of the present invention;
[0019] Figure 5 A flowchart of a processing method for a lock acquisition scenario where a coroutine that defines a lock and a coroutine to be locked are on different threads, provided by an embodiment of the present invention;
[0020] Figure 6 A flowchart of a method for successful one-time lock acquisition provided by an embodiment of the present invention;
[0021] Figure 7 A flowchart of a method for an unlock scenario provided by an embodiment of the present invention. Detailed implementation manners
[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the protection scope of the present invention.
[0023] It should be noted that in the description of the present invention, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present invention are used to distinguish similar objects, rather than to describe a specific order or sequence.
[0024] A thread is a job scheduling unit of the operating system kernel. Multiple threads on the operating system can form a thread group, which is also called a process coroutine. A coroutine, also known as a user-space thread, is a concurrent programming technique. The scheduling of coroutines is controlled in the user space, rather than through kernel scheduling.
[0025] In the related coroutine locking technical solution, in a lock competition scenario, when the lock acquisition fails, it is necessary to enter the kernel waiting queue, and the kernel intervenes to determine the lock owner. Figure 1 It is a schematic diagram of a scenario for handling lock competition by kernel intervention provided by an embodiment of the present invention. As Figure 1 shown, lock the coroutine; when it is detected that the lock acquisition is successful, the coroutine executes the critical section code; when it is detected that the lock acquisition fails, the coroutine is added to the kernel waiting queue and waits to execute the critical section code after being woken up by the kernel. In this scenario, the coroutine attempts to perform a locking operation in the user space. In a non-competition scenario, the lock operation is completely performed in the user space without kernel intervention; however, in a lock competition scenario, the kernel needs to intervene to determine the lock owner. The blocking wait during coroutine locking will cause the blocking of the thread where it is located, thus blocking all coroutines on that thread. In addition, in a scenario with intense lock competition, the context switch of the coroutine from the user space to the kernel space will be very frequent and the kernel queue may be long, which will overall slow down the system performance, and this solution violates the pure user-space implementation principle (to meet the high-performance requirements of the upper-layer services, some coroutine application systems are designed to be implemented in pure user space. Therefore, the coroutine lock must be implemented in pure user space, that is, no system call can be initiated in the implementation of the lock).
[0026] In a lock competition scenario, in the technical solution of locking by relevant coroutines, the mutual exclusion of access is also ensured through file locks. By locking files in the user-mode file system, the mutual execution rights among coroutines are achieved. That is, before a coroutine executes the critical section code, it must successfully lock a certain file. Only when the locking is successful can it execute the critical section, and if the locking fails, it cannot execute. The basic principle of file locks is that when a process performs input / output (I / O) operations on a file, it first locks the file and then performs read / write operations. As long as the process does not unlock the file, other processes will not be able to operate on it. Through the file lock method, the orderliness and mutual exclusion of access can indeed be satisfied, but when coroutines lock based on this method, they may be blocked due to file locking operations, affecting system performance. In addition, this solution depends on the external user-mode file system, increasing the dependence of the application system.
[0027] To solve the problem of blocking caused by locking, an embodiment of the present invention provides a high-performance mutex implementation applicable to coroutine scheduling to solve the problem of coroutine blocking caused by locks.
[0028] To enable those skilled in the art of this technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 2 It is a schematic diagram of a coroutine concurrency control method provided by an embodiment of the present invention. As Figure 2 shown, the method includes:
[0029] S10: When it is detected that the coroutine to be locked fails to lock, remove the coroutine to be locked from the ready queue and control the coroutine to be locked to yield the central processing unit; wherein, the coroutines in the ready queue are the coroutines to be executed by the scheduler;
[0030] S11: Use the event processor and / or use the auxiliary coroutine created based on the coroutine to be locked to control the lock user to be the coroutine to be locked; wherein, the event processor is used to process the lock request event or process the cross-thread migration event of the coroutine to be locked;
[0031] S12: Move the coroutine to be locked into the ready queue so that the scheduler can control the coroutine to be locked to perform operations on the shared resource area.
[0032] It should be noted that to improve system performance, the locking described in the present invention is to apply for locking through user-mode atomic instructions, which is very lightweight to improve system performance.
[0033] Locking a coroutine means calling a lock function. The lock state is maintained through atomic instructions in the lock function, and the thread identification (ID) and coroutine id of the coroutine (i.e. the user of the lock) that has successfully locked are recorded. The thread ID and coroutine id that are requesting the lock can be recorded in the lock waiting queue.
[0034] When locking a coroutine, the coroutine is placed in the ready queue. As described above, the coroutines in the ready queue are the coroutines to be executed by the scheduler. The results of locking a coroutine include successful locking and failed locking. The result after locking can be judged based on the value of the lock status. For example, if the lock status value is 1, it indicates that the lock is successful; if the lock status value is 0, it indicates that the lock fails. There is no limit on the coroutine to be locked, and it is determined according to the actual situation.
[0035] When it is detected that the locking of the coroutine to be locked fails, the coroutine to be locked is removed from the ready queue. In order to avoid blocking of the locked coroutine and the thread where the locked coroutine is located, the coroutine to be locked is controlled to give up the CPU.
[0036] In the case of detecting that the locking of the coroutine to be locked fails, the coroutine to be locked is removed from the ready queue and the coroutine to be locked is controlled to give up the central processor. In order to ensure that the coroutine to be locked can continue to get the lock, the embodiment of the present invention uses an event processor and / or an auxiliary coroutine created based on the coroutine to be locked to control the user of the lock to be the coroutine to be locked. That is, the user of the lock can be controlled to be the coroutine to be locked through the event processor, and the user of the lock can be controlled to be the coroutine to be locked through the auxiliary coroutine created based on the coroutine to be locked. The user of the lock can also be controlled to be the coroutine to be locked by using the event processor and the auxiliary coroutine created based on the coroutine to be locked.
[0037] It is worth noting that the auxiliary coroutine is a coroutine that takes the coroutine to be locked as a parameter and the secondary locking function as the entry function. In order to enable the auxiliary coroutine to quickly give the lock to the coroutine to be locked, in the implementation, the thread identifier of the coroutine to be locked and the coroutine identifier of the coroutine to be locked are pre-stored in the auxiliary coroutine. Creating an auxiliary coroutine to obtain a lock is also called the process of secondary locking.
[0038] Define the lock as a global or static variable in the form of a structure:
[0039] struct CoMutexLock {
[0040] int lock status; / / value 0 or 1
[0041] struct owner;
[0042] queue waiters;
[0043] void LockingFunction();
[0044] void UnlockingFunction();
[0045] void DoubleLockingFunction();
[0046] }
[0047] void LockingFunction() {
[0048] ……
[0049] if (lock - fail) {
[0050] ……
[0051] yield;
[0052] }
[0053] return; / / Return indicates successful locking
[0054] }
[0055] After using the event handler and / or using the auxiliary coroutine created based on the coroutine to be locked to control the lock user to be the coroutine to be locked, the coroutine to be locked is put back into the ready queue so that the scheduler can control the coroutine to be locked to execute the operation of accessing the shared resource area, that is, execute the code in the critical section.
[0056] In this method, when it is detected that the coroutine to be locked fails to obtain the lock, the coroutine to be locked is removed from the ready queue and the coroutine to be locked is controlled to yield the central processing unit, avoiding the blocking of the locking coroutine and the blocking on the thread where the locking coroutine is located. Secondly, after the coroutine to be locked yields the central processing unit, the event processor and / or the auxiliary coroutine created based on the coroutine to be locked are used to control the lock user to be the coroutine to be locked, that is, to enable the coroutine to be locked to successfully obtain the lock. After successfully obtaining the lock, the coroutine to be locked is moved into the ready queue. Under the control of the scheduler, the coroutine to be locked in the ready queue can perform the operation of accessing the shared resource area, avoiding the occurrence of data inconsistency problems when multiple coroutines access shared data simultaneously. Thirdly, when implementing the lock user as the coroutine to be locked, it can be achieved through the event processor, through the auxiliary coroutine created based on the coroutine to be locked, or jointly through the event processor and the auxiliary coroutine created based on the coroutine to be locked, improving the flexibility of the method for implementing the control of the lock user as the coroutine to be locked. In addition, in the case where the coroutine fails to obtain the lock and needs to enter the kernel waiting queue for the kernel to intervene to determine the lock owner, in the method provided by the present invention, the event processor and / or the auxiliary coroutine created based on the coroutine to be locked are used to control the lock user to be the coroutine to be locked, which is implemented in pure user mode. Therefore, there is no situation where the context switch of the coroutine initiating a system call from user mode to kernel mode is very frequent and the kernel queue may be long, which will generally slow down the system performance and violate the disadvantage of the pure user mode implementation of the coroutine. In addition, compared with the method of using file locks, in the method provided by the present invention, no file is locked, avoiding the situation where the system performance is affected due to the blocking caused by file locking operations.
[0057] In some embodiments, detecting whether the coroutine to be locked successfully obtains the lock or fails to obtain the lock includes:
[0058] Detecting whether the coroutine to be locked successfully obtains the lock or fails to obtain the lock when the coroutine to be locked and the coroutine that has not released the lock are in different threads or the same thread.
[0059] In these two scenarios of lock acquisition failure (respectively: when the coroutine to be locked and the coroutine that has not released the lock are in different threads, it is detected that the coroutine to be locked fails to obtain the lock; when the coroutine to be locked and the coroutine that has not released the lock are in the same thread, it is detected that the coroutine to be locked fails to obtain the lock), in order to enable the coroutine to be locked to obtain the lock again, controlling the lock user to be the coroutine to be locked by using the auxiliary coroutine created based on the coroutine to be locked includes:
[0060] Adding the auxiliary coroutine created based on the coroutine to be locked to the ready queue through the lock acquisition function;
[0061] Controlling the auxiliary coroutine to execute the secondary lock acquisition function through the scheduler;
[0062] After detecting that the auxiliary coroutine has successfully locked, control the user of the lock to be the coroutine waiting to lock.
[0063] That is, through the auxiliary coroutine, the user of the lock is the coroutine waiting to lock. To reduce the space occupied by the auxiliary coroutine, after detecting that the auxiliary coroutine has successfully locked and controlling the user of the lock to be the coroutine waiting to lock, it further includes:
[0064] Move the auxiliary coroutine into the coroutine destruction queue and control the auxiliary coroutine to yield the central processing unit.
[0065] After the scheduler controls the auxiliary coroutine to execute the secondary locking function, it is also possible that the auxiliary coroutine fails to lock. To ensure that the secondary locking function makes multiple locking requests until the request is successful, after controlling the auxiliary coroutine to execute the secondary locking function through the scheduler, it further includes:
[0066] After detecting that the auxiliary coroutine fails to lock, control the auxiliary coroutine to yield the execution right for representing the execution of locking, and return to the step of controlling the auxiliary coroutine to execute the secondary locking function through the scheduler.
[0067] It should be noted that the coroutine 1 on thread 1 described below is used to identify that the coroutine requesting to lock is a certain coroutine running on thread 1, and it is identified by coroutine 1. The coroutine N on thread M described below is similar, which means a certain coroutine running on thread M is identified by coroutine N.
[0068] For the scenario where multiple threads jointly maintain the lock state in a multi-threaded environment and are implemented based on stackful coroutines. Among them, stackful coroutines refer to: when the coroutine runs, the data is stored on the stack allocated by the system on the heap. To solve the long-tail problem, the coroutine library generally needs to support multiple threads. The following specifically describes the above two scenarios of locking failure. In addition, it is worth noting that the locking coroutine described below is the same as the coroutine waiting to lock described above.
[0069] Basic locking failure scenario 1 (the coroutine that has not released the lock and the coroutine requesting the lock are not on the same thread):
[0070] If coroutine 2 on thread 2 calls the locking function to lock lock A but fails to lock. This is because there is already a coroutine that has locked lock A but has not released lock A.
[0071] Assume that the failure of coroutine 2 on thread 2 to lock is caused by coroutine 1 on thread 1 not releasing lock A, that is, the coroutine that has not released the lock and the coroutine requesting the lock are not on the same thread.
[0072] The exception handling process for locking failure scenario 1 is:
[0073] The locking function removes coroutine 2 on thread 2 from the ready queue of thread 2. The locking function creates a coroutine Z1 with coroutine 2 on thread 2 as the parameter and the double-locking function as the entry function (in the function implementation of the double-locking function, the parameter coroutine 2 on thread 2 is saved as a local variable on the stack of the stackful coroutine Z1). The locking function adds coroutine Z1 of thread 2 to the ready coroutine queue of thread 2. The locking function performs a yield operation (i.e., yields the central processing unit).
[0074] The yield operation when the locking function fails to lock is as follows:
[0075] void lockingFunction() {
[0076] ……
[0077] if (lock-fail) {
[0078] ……
[0079] yield;
[0080] }
[0081] return; / / Returns indicating successful locking
[0082] }
[0083] After coroutine 2 on thread 2 is suspended through the yield operation of the locking function, the execution right of thread 2 returns to the event loop of thread 2 (i.e., the scheduler).
[0084] Since coroutine Z1 of thread 2 is already in the ready coroutine queue of thread 2, coroutine Z1 of thread 2 is scheduled to execute. Coroutine Z1 of thread 2 executes the double-locking function. The double-locking function locks lock A through an atomic instruction. If the locking fails, coroutine Z1 yields the execution right (coroutine Z1 is still in the coroutine ready queue) and waits for the next scheduling.
[0085] If the locking is successful, the coroutine waiting for lock A is identified from its stack local variable. Here, it is coroutine 2 of thread 2. The owner of lock A is updated to coroutine 2 of thread 2, and coroutine 2 of thread 2 is added to the ready queue of thread 2. Then, the double-locking function puts coroutine Z1 into the coroutine destruction queue, and then performs a yield operation. The execution right of thread 2 returns to the event loop of thread 2 (i.e., the scheduler). After coroutine 2 of thread 2 is scheduled to be given the execution right, it is allowed to execute critical section 1.
[0086] Figure 3 The flowchart of the processing method for the scenario where the coroutine that has not released the lock and the coroutine that requests the lock are not on the same thread provided by the embodiment of the present invention. As Figure 3 shown, the method includes:
[0087] S13: Atomically lock (lock A);
[0088] S14: Determine whether the lock is successfully acquired; if not, proceed to step S15;
[0089] S15: Remove the locking coroutine from the ready queue;
[0090] S16: Create coroutine Z1 (re-lock);
[0091] S17: Add the new coroutine Z1 to the ready queue;
[0092] S18: The locking coroutine yields the central processing unit;
[0093] S19: The new coroutine Z1 is scheduled;
[0094] S20: Atomically lock (lock A);
[0095] S21: Determine whether the re-locking is successful; if not, proceed to step S22 and return to step S19; if so, proceed to step S23;
[0096] S22: The new coroutine Z1 waits for the next scheduling;
[0097] S23: Update the user of (lock A) to the locking coroutine;
[0098] S24: Add the locking coroutine to the ready queue;
[0099] S25: Add Z1 to the destruction queue;
[0100] S26: The Z1 coroutine yields the central processing unit;
[0101] S27: Resume the execution of the locking coroutine;
[0102] S28: Execute critical section 1.
[0103] Basic scenario 2 of lock acquisition failure (the lock acquisition failure of the coroutine requesting the lock is caused by another coroutine on the same thread not releasing the lock, that is, the coroutine not releasing the lock and the coroutine requesting the lock are on the same thread):
[0104] Suppose that after coroutine 1 on thread 1 acquires the lock and has not released it yet, and at this time coroutine 3 on thread 1 requests the lock. The exception handling process for coroutine 3's lock acquisition failure is similar to that of scenario 4 (for the specific process, see the steps above Figure 3 ):
[0105] After the coroutine 3 fails to acquire the lock, the lock acquisition function removes coroutine 3 on thread 1 from the ready coroutine queue of thread 1. The lock acquisition function creates a coroutine Z2 with coroutine 3 on thread 1 as the parameter and the secondary lock acquisition function as the entry function (in the secondary lock acquisition function, the parameter coroutine 3 on thread 1 is saved as a local variable on the stack of the stackful coroutine Z2). The lock acquisition function adds coroutine Z2 of thread 1 to the ready coroutine queue of thread 1. The lock acquisition function performs a yield operation, and the execution right of thread 2 returns to the event loop of thread 2 (i.e., the scheduler). After Z2 executes a logic similar to Z1, coroutine 3 on thread 1 is scheduled to execute and is allowed to execute the critical section 1.
[0106] In practice, some architectures (such as coroutine application systems on Non-Uniform Memory Access (NUMA)) are customized. The characteristics of such systems are that the threads on each Central Processing Unit (CPU) core are bound to the core, and the threads have independent resources such as memory, network stack, and CPU. Coroutines access the mutex defined by the lock through the event interface.
[0107] For the scenario of such a core-bound architecture, detecting whether the coroutine to be locked succeeds or fails to acquire the lock includes:
[0108] When the coroutine defining the lock and the coroutine to be locked are on the same thread, detecting whether the coroutine to be locked succeeds or fails to acquire the lock;
[0109] Before removing the coroutine to be locked from the ready queue and controlling the coroutine to be locked to yield the central processing unit, it further includes:
[0110] Issuing a lock acquisition request event; wherein, the lock acquisition request event is constructed by wrapping the coroutine to be locked and the lock to be used into an event structure;
[0111] After removing the coroutine to be locked from the ready queue and controlling the coroutine to be locked to yield the central processing unit, it further includes:
[0112] Scheduling the lock acquisition request event and entering the step of using the event processor to control the user of the lock to be the coroutine to be locked;
[0113] Using the event processor to control the user of the lock to be the coroutine to be locked includes:
[0114] Performing lock acquisition processing on the coroutine to be locked according to the lock acquisition request event in the event processor;
[0115] After detecting that the coroutine to be locked succeeds in acquiring the lock, controlling the user of the lock to be the coroutine to be locked.
[0116] In the event processor, when locking the coroutine to be locked according to the lock request event, it may fail to lock. To ensure successful locking, after locking the coroutine to be locked according to the lock request event in the event processor, it further includes:
[0117] Pre-create a coroutine waiting queue corresponding to the lock to be used;
[0118] After detecting that the coroutine to be locked fails to lock, add the coroutine to be locked to the coroutine waiting queue.
[0119] The following specifically describes the locking scenario where the coroutine defining the lock and the coroutine to be locked are in the same thread. In the core-binding architecture, the locking scenario where the coroutine defining the lock and the coroutine to be locked are in the same thread is called the basic locking scenario 3.
[0120] A certain coroutine on the coroutine defining the lock requests to lock. The coroutine 1 of the lock definition thread calls the lock function. The lock function determines that the requesting thread is the lock definition thread, wraps the coroutine 1 of the lock definition thread and lock B into an event structure to construct a lock request type event, and sends the event to the local thread. The lock function removes the coroutine 1 of the lock definition thread from the ready queue, then executes the yield statement, and the execution right is given to the event loop of the lock definition thread. The processing function of the lock request event discovers from the event structure that it is the lock B lock request initiated by the coroutine 1 of the lock definition thread. If the lock is successfully acquired through an atomic instruction (at this time, the lock state changes from 0 to 1), then update the user thread ID and coroutine ID of lock B to the coroutine 1 of the lock definition thread, and add the coroutine 1 of the lock definition thread to the ready queue. If coroutine 1 is scheduled, it is allowed to execute the critical section 2. If the lock acquisition fails, add the coroutine 1 of the lock definition thread to the waiting queue of lock B.
[0121] Figure 4 It is a flowchart of a method for processing the locking scenario where the coroutine defining the lock and the coroutine to be locked are in the same thread provided by an embodiment of the present invention. As Figure 4 shown, the method includes:
[0122] S29: Determine whether the locking coroutine and the lock definition coroutine are on the same thread; if so, enter step S30;
[0123] S30: Issue a lock request event;
[0124] S31: Remove the locking coroutine from the ready queue;
[0125] S32: The locking coroutine yields the central processing unit;
[0126] S33: The lock request event processor is scheduled;
[0127] S34: Atomically lock (lock B);
[0128] S35: Determine whether the locking is successful; if not, go to step S36; if so, go to step S37;
[0129] S36: The locking coroutine enters the waiting queue of lock B;
[0130] S37: Update the user of (lock B) to the locking coroutine;
[0131] S38: The locking coroutine enters the ready queue;
[0132] S39: The event processor finishes processing and enters the event loop;
[0133] S40: The locking coroutine resumes execution;
[0134] S41: Execute critical section 2.
[0135] The above process describes the processing method for the locking scenario where the coroutine defining the lock and the coroutine waiting to lock are in the same thread in the core-binding architecture. For the core-binding architecture, there may also be a locking scenario where the coroutine defining the lock and the coroutine waiting to lock are in different threads. Detecting whether the coroutine waiting to lock is locked successfully or failed includes:
[0136] In the case where the coroutine defining the lock and the coroutine waiting to lock are in different threads, detect whether the coroutine waiting to lock is locked successfully or failed.
[0137] Before controlling the coroutine waiting to lock to yield the central processing unit, it further includes:
[0138] Migrate the coroutine waiting to lock to the thread where the coroutine defining the lock is located;
[0139] Initiate a coroutine migration event;
[0140] Using the event processor and an auxiliary coroutine created based on the coroutine waiting to lock, controlling the user of the lock to be the coroutine waiting to lock includes:
[0141] Schedule the coroutine migration event and determine the coroutine waiting to lock according to the coroutine migration event;
[0142] Create an auxiliary coroutine based on the coroutine waiting to lock and add the auxiliary coroutine to the ready queue;
[0143] Control the auxiliary coroutine to execute the secondary locking function through the scheduler;
[0144] After detecting that the auxiliary coroutine is locked successfully, control the user of the lock to be the coroutine waiting to lock.
[0145] In order to reduce the space occupied by the auxiliary coroutine, after detecting that the auxiliary coroutine is locked successfully and controlling the user of the lock to be the coroutine waiting to lock, it further includes:
[0146] Move the auxiliary coroutine to the coroutine destruction queue and control the auxiliary coroutine to give up the central processor.
[0147] After the scheduler controls the auxiliary coroutine to execute the secondary lock function, the auxiliary coroutine may fail to lock. In order to ensure that the secondary lock function executes the lock request multiple times until the request succeeds, after the scheduler controls the auxiliary coroutine to execute the secondary lock function, it also includes:
[0148] After detecting that the auxiliary coroutine fails to lock, the auxiliary coroutine is controlled to give up the execution right used to characterize the execution lock, and the process returns to the step of controlling the auxiliary coroutine to execute the secondary lock function through the scheduler.
[0149] The following is a detailed description of the above locking scenario where the coroutine defining the lock and the coroutine to be locked are located in different threads. Under the bound core architecture, the locking scenario where the coroutine defining the lock and the coroutine to be locked are located in different threads is called basic locking scenario 4.
[0150] A coroutine on a thread other than the thread where the lock coroutine is defined requests to lock. Thread 2 (non-lock definition thread) coroutine 2 calls the lock function. The lock function determines that thread 2 is a non-lock definition thread, calls the submit_to interface provided by the system, suspends itself (i.e. coroutine 2), moves it to the lock definition thread's move-in queue (becomes lock definition thread coroutine 2), initiates a coroutine move-in event, and then the lock function yields. When a coroutine move-in event is encountered in the event loop, the lock definition thread coroutine 2 is located through the coroutine move-in event processing function, and then a coroutine Z3 is created with the lock definition thread coroutine 2 as a parameter and the secondary lock function as the entry function. The move-in event processing function puts coroutine Z3 into the ready queue. When Z3 obtains the execution right, the lock is successfully locked through the atomic instruction (the lock state changes from 0 to 1 at this time), and the user thread ID and coroutine id of lock B are updated to the lock definition thread coroutine 2, and the lock definition thread coroutine 2 is added to the lock definition thread ready queue. Z3 adds itself to the coroutine destruction queue and yields. If coroutine 2 is scheduled, it is allowed to execute critical section 2. If locking through atomic instructions fails, yield is executed (still in the ready queue) and waits for the next scheduling execution.
[0151] Figure 5 A flowchart of a method for processing a locking scenario in which a coroutine defining a lock and a coroutine to be locked are located in different threads is provided in an embodiment of the present invention. Figure 5 As shown, the method includes:
[0152] S42: Determine whether the locking coroutine and the lock definition coroutine are on the same thread; if not, proceed to step S43;
[0153] S43: Migrate the locking coroutine to the lock definition thread;
[0154] S44: Define a coroutine migration event for the lock-defining thread;
[0155] S45: The locking coroutine yields the central processing unit;
[0156] S46: The coroutine migration event handler is scheduled;
[0157] S47: Create coroutine Z3 (double locking);
[0158] S48: The new coroutine Z3 enters the ready queue;
[0159] S49: The event handler ends processing and enters the event loop;
[0160] S50: The new coroutine Z3 is scheduled;
[0161] S51: Atomically lock (lock B);
[0162] S52: Determine whether the locking is successful; if not, go to step S53 and return to step S50; if so, go to step S54;
[0163] S53: The new coroutine Z3 waits to be scheduled next time;
[0164] S54: Update the user of (lock B) to the locking coroutine;
[0165] S55: The locking coroutine enters the ready queue;
[0166] S56: Z3 enters the destruction queue;
[0167] S57: Coroutine Z3: Yield the central processing unit;
[0168] S58: The locking coroutine resumes execution;
[0169] S59: Execute critical section 2.
[0170] The above text describes the handling method for the scenario of locking failure. In practice, there will also be a scenario where the locking is successful. The coroutine concurrency control method also includes:
[0171] Since starting to lock the coroutine waiting to be locked, if it is detected that the coroutine waiting to be locked has successfully locked, control the user of the lock to be the coroutine waiting to be locked;
[0172] Control the coroutine waiting to be locked to execute an operation to access the shared resource area through the scheduler.
[0173] The above process can be called a scenario of successful one-time locking. The following describes the basic scenario 1 of successful locking. A certain coroutine (assumed to be "coroutine 1 on thread 1") calls the locking function. If the locking function successfully locks through an atomic instruction (assumed to be lock A) (at this time, the lock state changes from 0 to 1), the user thread ID and coroutine ID of lock A are updated. Coroutine 1 is allowed to execute the critical section 1. Figure 6 is a flowchart of a method for successful one-time locking provided by an embodiment of the present invention, as Figure 6 shown, the method includes:
[0174] S60: Lock with an atomic instruction (lock A);
[0175] S61: Determine whether the locking is successful; if so, enter step S62;
[0176] S62: Update lock A as the user of the lock;
[0177] S63: Execute the critical section 1.
[0178] The following provides another basic scenario 2 of successful locking.
[0179] Scenario 2 describes the locking situation of a coroutine on another thread.
[0180] Similar to the successful locking of coroutine 1 on thread 1, if coroutine 2 on thread 2 calls the locking function to lock lock A and the locking is successful, the locking function updates the user of lock A to coroutine 2 of thread 2, and coroutine 2 is allowed to execute the critical section 1.
[0181] The successful locking scenarios of coroutine 1 on thread 1 and coroutine 2 on thread 2 can be marked as successful one-time locking. There is a situation where the locking is successful with one locking request.
[0182] After the coroutine to be locked is successfully locked, it further includes:
[0183] Obtain the unlocking function, and use the coroutine to be locked that has been successfully locked as the coroutine to be unlocked;
[0184] Unlock the coroutine to be unlocked by using the unlocking function.
[0185] In order to achieve accurate unlocking, unlocking the coroutine to be unlocked by using the unlocking function includes:
[0186] Judge whether the user of the lock is the target unlocking coroutine through the unlocking function;
[0187] If so, unlock the target unlocking coroutine by using the unlocking function;
[0188] If not, output a prompt message indicating the misuse of the unlocking function, and destroy the target unlocking coroutine.
[0189] For the unlocking process, unlocking scenario 1 is described below. When the coroutine 1 on thread 1 calls the unlocking function to unlock lock A, the unlocking function determines whether the owner of lock A is the coroutine 1 on thread 1. If not (this is a case of misusing the unlocking function), the coroutine is destroyed; if so, it unlocks through an atomic instruction (at this time, the lock state changes from 1 to 0). Figure 7 It is a flowchart of a method for an unlocking scenario provided by an embodiment of the present invention, as Figure 7 shown. The method includes:
[0190] S64: Determine whether the user of the lock is the unlocking requester; if so, go to step S65; if not, go to step S66;
[0191] S65: Unlock through an atomic instruction;
[0192] S66: Destroy the requester coroutine.
[0193] In practice, unlocking scenario 2 may also occur. There may be multiple coroutines waiting to lock in the waiting lock queue. In order to trigger the scheduling of the coroutines waiting to lock, after using the unlocking function to unlock the target unlocking coroutine, or after destroying the target unlocking coroutine, it further includes:
[0194] Use the unlocking function to check whether the waiting lock queue of the target lock is empty;
[0195] If so, end;
[0196] If not, obtain the coroutine waiting to lock from the head of the waiting lock queue; put the coroutine waiting to lock into the ready queue so that the scheduler can control the coroutine waiting to lock to execute the operation of accessing the shared resource area.
[0197] For unlocking scenario 2, a certain coroutine 5 in the lock definition thread calls the unlocking function. The unlocking function determines whether the owner of lock B is coroutine 5. If not (this is a case of misusing the unlocking function), the coroutine is destroyed; if so, the unlocking function checks whether the waiting lock queue of lock B is NULL. If it is NULL, the function returns. If it is not NULL, the next element is removed from the head of the waiting queue. The unlocking function unlocks successfully through an atomic instruction (at this time, the lock state changes from 1 to 0), and the coroutine represented by the element removed from the head of the waiting lock queue (assumed to be coroutine 6) is put into the ready queue. After being scheduled, coroutine 6 is allowed to execute critical section 2.
[0198] In the scenario provided by the present invention, the unlocking function wakes up the coroutines waiting to lock in the lock waiting queue, ensuring that the coroutines in the lock waiting queue can be scheduled, so that they can execute the critical section code and access the shared resource area.
[0199] In the coroutine concurrency control method provided by the embodiment of the present invention, when the coroutine fails to lock, the blocking of the locked coroutine is avoided by the yield operation, so that the high performance of the system can be better exerted; the orderliness of the locked coroutine's access to the critical area is ensured by moving the locked coroutine out of and into the ready queue; a secondary locking function is designed for the auxiliary coroutine, and the auxiliary coroutine supports the round-robin execution of the lock request well with the help of the scheduling execution of the ready coroutine; the coroutine applies for locking through the user-mode atomic instruction, which is very lightweight and improves the system performance; supports the cross-thread migration of the coroutine; the implemented high-performance lock can be integrated into the coroutine library that does not provide a locking mechanism, providing a relatively complete coroutine library implementation for business applications. The implemented high-performance lock can replace the coroutine lock implementation based on the calling kernel mechanism and other mechanisms to make up for the performance loss of the coroutine library; the implemented high-performance lock increases the possibility of large-scale design or application of high-performance user-mode systems without kernel restrictions, which helps to enrich the application ecology of coroutines.
[0200] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.
[0201] A coroutine concurrency control method is described above. This embodiment further provides a coroutine concurrency control device, which includes:
[0202] A removal and control module is used to remove the coroutine to be locked from the ready queue and control the coroutine to be locked to give up the central processor when it is detected that the coroutine to be locked fails to be locked; wherein the coroutine in the ready queue is the coroutine to be executed by the scheduler;
[0203] A control module, used to control the lock user to be the coroutine to be locked by using an event processor and / or an auxiliary coroutine created based on the coroutine to be locked; wherein the event processor is used to process a lock request event or a cross-thread migration event of the coroutine to be locked;
[0204] The move-in module is used to move the coroutine to be locked into the ready queue so that the scheduler can control the coroutine to be locked to perform operations to access the shared resource area.
[0205] In some embodiments, the coroutine concurrency control device includes a first detection module, which is used to detect whether the coroutine to be locked is locked successfully or failed.
[0206] The first detection module is specifically used to detect whether the locking of the coroutine to be locked is successful or failed when the coroutine to be locked and the coroutine that has not released the lock are located in different threads or the same thread.
[0207] In some embodiments, the coroutine concurrency control device includes a first control module configured to control the lock user as the coroutine to be locked by using an auxiliary coroutine created based on the coroutine to be locked.
[0208] The first control module specifically includes:
[0209] An addition module configured to add an auxiliary coroutine created based on the coroutine to be locked to the ready queue through a locking function;
[0210] A first execution module configured to control the auxiliary coroutine to execute a secondary locking function through a scheduler;
[0211] A first control sub-module configured to control the lock user as the coroutine to be locked after detecting that the auxiliary coroutine has successfully locked.
[0212] In some embodiments, the coroutine concurrency control device further includes:
[0213] A moving-in and control module configured to move the auxiliary coroutine into the coroutine destruction queue and control the auxiliary coroutine to yield the central processing unit;
[0214] In some embodiments, the coroutine concurrency control device further includes:
[0215] A first detection and control module configured to control the auxiliary coroutine to yield the execution right for representing locking and return to trigger the first execution module after detecting that the auxiliary coroutine has failed to lock.
[0216] In some embodiments, the coroutine concurrency control device includes a second detection module configured to detect whether the coroutine to be locked has successfully or failed to lock.
[0217] The second detection module is specifically configured to detect whether the coroutine to be locked has successfully or failed to lock when the coroutine defining the lock and the coroutine to be locked are in the same thread.
[0218] In some embodiments, the coroutine concurrency control device further includes:
[0219] An issuing module configured to issue a lock request event; wherein, the lock request event is constructed by wrapping the coroutine to be locked and the lock to be used into an event structure;
[0220] In some embodiments, the coroutine concurrency control device further includes:
[0221] A scheduling module configured to schedule the lock request event and control the lock user as the coroutine to be locked by using an event processor;
[0222] The coroutine concurrency control device includes a second control module configured to control the lock user as the coroutine to be locked by using an event processor.
[0223] The second control module specifically includes:
[0224] The lock processing module is used to perform lock processing on the coroutine to be locked according to the lock request event in the event processor;
[0225] The second control submodule is used to control the user of the lock to be the coroutine to be locked after detecting that the coroutine to be locked is locked successfully.
[0226] In some embodiments, the coroutine concurrency control device further includes:
[0227] Create a module to pre-create a coroutine waiting queue corresponding to the lock to be used;
[0228] The detection and joining module is used to add the coroutine to be locked to the coroutine waiting queue after detecting that the coroutine to be locked fails to be locked.
[0229] In some embodiments, the coroutine concurrency control device includes a third detection module, which is used to detect whether the coroutine to be locked is locked successfully or failed.
[0230] The third detection module is specifically used for: when the coroutine defining the lock and the coroutine to be locked are located in different threads, detecting whether the coroutine to be locked is locked successfully or failed.
[0231] The coroutine concurrency control device also includes:
[0232] Migration module, used to migrate the coroutine to be locked to the thread where the coroutine that defines the lock is located;
[0233] The initiating module is used to initiate the coroutine move-in event;
[0234] The coroutine concurrency control device includes a third control module, which is used to use an event processor and an auxiliary coroutine created based on the coroutine to be locked, and the user of the control lock is the coroutine to be locked.
[0235] The third control module includes:
[0236] The scheduling and determination module is used to schedule the coroutine entry event and determine the coroutine to be locked according to the coroutine entry event;
[0237] The creation and joining module is used to create auxiliary coroutines based on the coroutine to be locked, and add the auxiliary coroutines to the ready queue;
[0238] The second execution module is used to control the auxiliary coroutine to execute the secondary locking function through the scheduler;
[0239] The third control submodule is used to control the user of the lock to be the coroutine to be locked after detecting that the auxiliary coroutine is locked successfully.
[0240] In some embodiments, the coroutine concurrency control device further includes:
[0241] A moving-in and yielding module, configured to move an auxiliary coroutine into a coroutine destruction queue and control the auxiliary coroutine to yield the central processing unit;
[0242] It further includes: a detection and yielding module, configured to, after detecting that an auxiliary coroutine fails to lock, control the auxiliary coroutine to yield the execution right for representing locking execution, and return to trigger the second execution module.
[0243] In some embodiments, the coroutine concurrency control device further includes:
[0244] A second detection module, configured to, since starting to lock a coroutine to be locked, if it detects that the coroutine to be locked successfully locks, control the user of the lock to be the coroutine to be locked;
[0245] A third execution module, configured to control the coroutine to be locked to perform an operation of accessing a shared resource area through a scheduler.
[0246] In some embodiments, the coroutine concurrency control device further includes:
[0247] An obtaining and acting as module, configured to obtain an unlocking function and use the coroutine to be locked that has successfully locked as the coroutine to be unlocked;
[0248] An unlocking module, configured to use the unlocking function to unlock the coroutine to be unlocked.
[0249] The unlocking module specifically includes:
[0250] A judgment module, configured to judge whether the user of the lock is the target unlocking coroutine through the unlocking function; if so, trigger the unlocking sub-module; if not, trigger the output and destruction module;
[0251] An unlocking sub-module, configured to use the unlocking function to unlock the target unlocking coroutine;
[0252] An output and destruction module, configured to output a prompt message for representing misusing the unlocking function and destroy the target unlocking coroutine.
[0253] For the description of the features in the corresponding embodiments of the coroutine concurrency control device, reference can be made to the relevant description in the corresponding embodiments of the coroutine concurrency control method, which will not be elaborated here one by one.
[0254] An embodiment of the present invention further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above-mentioned embodiments of the coroutine concurrency control method.
[0255] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the coroutine concurrency control method when running.
[0256] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memories (ROMs for short), random access memories (RAMs for short), external hard drives, magnetic disks, or optical discs that can store computer programs.
[0257] Embodiments of the present invention also provide a computer program product, where the computer program product includes a computer program, and the computer program implements the steps in any of the above embodiments of the coroutine concurrency control method when executed by a processor.
[0258] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, and the computer program implements the steps in any of the above embodiments of the coroutine concurrency control method when executed by a processor.
[0259] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.
[0260] The above has introduced in detail a coroutine concurrency control method, an electronic device, a medium, and a product provided by the present invention. Specific examples are used herein to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.
Claims
1. A coroutine concurrency control method, characterized in that Including: When it is detected that the coroutine to be locked fails to obtain the lock, removing the coroutine to be locked from the ready queue and controlling the coroutine to be locked to yield the central processing unit; wherein, the coroutines in the ready queue are the coroutines to be executed by the scheduler; Using an event processor and / or an auxiliary coroutine created based on the coroutine to be locked, controlling the lock user to be the coroutine to be locked; wherein, the event processor is used to process the lock acquisition request event or the cross-thread migration event of the coroutine to be locked; Moving the coroutine to be locked into the ready queue so that the scheduler controls the coroutine to be locked to perform an operation of accessing the shared resource area.
2. The coroutine concurrency control method according to claim 1, wherein The auxiliary coroutine is a coroutine taking the coroutine to be locked as a parameter and using a double-lock function as an entry function; the thread identifier where the coroutine to be locked is located and the coroutine identifier of the coroutine to be locked are pre-stored in the auxiliary coroutine.
3. The coroutine concurrency control method according to claim 2, wherein Detecting whether the coroutine to be locked successfully obtains the lock includes: When the coroutine to be locked and the coroutine that has not released the lock are in different threads or the same thread, detecting whether the coroutine to be locked successfully obtains the lock.
4. The coroutine concurrency control method according to claim 3, wherein Using an auxiliary coroutine created based on the coroutine to be locked to control the lock user to be the coroutine to be locked includes: Adding the auxiliary coroutine created based on the coroutine to be locked to the ready queue through a lock acquisition function; Controlling the auxiliary coroutine to execute the double-lock function through the scheduler; After detecting that the auxiliary coroutine successfully obtains the lock, controlling the lock user to be the coroutine to be locked.
5. The coroutine concurrency control method according to claim 4, wherein After detecting that the auxiliary coroutine successfully obtains the lock and controlling the lock user to be the coroutine to be locked, it further includes: Moving the auxiliary coroutine into the coroutine destruction queue and controlling the auxiliary coroutine to yield the central processing unit; After controlling the auxiliary coroutine to execute the double-lock function through the scheduler, it further includes: After detecting that the auxiliary coroutine fails to obtain the lock, controlling the auxiliary coroutine to yield the execution right for representing lock acquisition, and returning to the step of controlling the auxiliary coroutine to execute the double-lock function through the scheduler.
6. The coroutine concurrency control method according to claim 1, characterized in that Detecting whether the coroutine to be locked successfully obtains the lock includes: When the coroutine defining the lock and the coroutine to be locked are in the same thread, detecting whether the coroutine to be locked successfully obtains the lock; Before removing the coroutine to be locked from the ready queue and controlling the coroutine to be locked to yield the central processing unit, it further includes: Issuing a lock acquisition request event; wherein, the lock acquisition request event is constructed by wrapping the coroutine to be locked and the lock to be used into an event structure; After removing the coroutine to be locked from the ready queue and controlling the coroutine to be locked to yield the central processing unit, it further includes: Scheduling the lock acquisition request event and using the event processor to control the lock user to be the coroutine to be locked; Using the event processor to control the lock user to be the coroutine to be locked includes: Performing lock acquisition processing on the coroutine to be locked according to the lock acquisition request event in the event processor; After detecting that the coroutine to be locked successfully obtains the lock, controlling the lock user to be the coroutine to be locked.
7. The coroutine concurrency control method according to claim 6, wherein After performing a locking process on the coroutine to be locked according to the lock request event in the event processor, the following steps are further included: Pre-create a coroutine waiting queue corresponding to the lock to be used; After detecting that the coroutine to be locked fails to obtain the lock, add the coroutine to the coroutine waiting queue.
8. The coroutine concurrency control method according to claim 2, wherein Detecting whether the coroutine to be locked successfully obtains the lock includes: In the case where the coroutine defining the lock and the coroutine to be locked are in different threads, detect whether the coroutine to be locked successfully obtains the lock; Before controlling the coroutine to be locked to yield the central processing unit, the following steps are further included: Migrate the coroutine to be locked to the thread where the coroutine defining the lock is located; Initiate a coroutine migration event; Controlling the lock user to be the coroutine to be locked by using the event processor and an auxiliary coroutine created based on the coroutine to be locked includes: Schedule the coroutine migration event and determine the coroutine to be locked according to the coroutine migration event; Create an auxiliary coroutine based on the coroutine to be locked and add the auxiliary coroutine to the ready queue; Control the auxiliary coroutine to execute a secondary locking function through the scheduler; After detecting that the auxiliary coroutine successfully obtains the lock, control the lock user to be the coroutine to be locked.
9. The coroutine concurrency control method according to claim 8, wherein, After detecting that the auxiliary coroutine successfully obtains the lock and controlling the lock user to be the coroutine to be locked, the following steps are further included: Move the auxiliary coroutine to the coroutine destruction queue and control the auxiliary coroutine to yield the central processing unit; After controlling the auxiliary coroutine to execute the secondary locking function through the scheduler, the following steps are further included: After detecting that the auxiliary coroutine fails to obtain the lock, control the auxiliary coroutine to yield the execution right for locking, and return to the step of controlling the auxiliary coroutine to execute the secondary locking function through the scheduler.
10. The coroutine concurrency control method according to any one of claims 1 to 9, characterized in that The following steps are further included: Since starting to lock the coroutine to be locked, if it is detected that the coroutine to be locked successfully obtains the lock, control the lock user to be the coroutine to be locked; Control the coroutine to be locked to execute an operation on the shared resource area through the scheduler.
11. The coroutine concurrency control method according to claim 10, wherein After the coroutine to be locked successfully obtains the lock, the following steps are further included: Obtain an unlocking function, and use the coroutine to be locked that has successfully obtained the lock as the coroutine to be unlocked; Use the unlocking function to unlock the coroutine to be unlocked.
12. The coroutine concurrency control method according to claim 11, wherein The step of using the unlocking function to unlock the coroutine to be unlocked includes: Judge whether the lock user is the target unlocking coroutine through the unlocking function; If so, use the unlocking function to unlock the target unlocking coroutine; If not, output a prompt message indicating misusing the unlocking function, and destroy the target unlocking coroutine.
13. An electronic device, characterized in that, It includes: A memory for storing a computer program; A processor for implementing the steps of the coroutine concurrency control method according to any one of claims 1 to 12 when executing the computer program.
14. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program, when executed by the processor, implements the steps of the coroutine concurrency control method according to any one of claims 1 to 12.
15. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the coroutine concurrency control method according to any one of claims 1 to 12.