A thread management method, device and related equipment

Abstract

This application provides a thread management method, apparatus, and related devices. The method includes: when multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in a first state, where the first state indicates that the mutex lock is occupied; if the mutex lock is in the first state, the thread determines whether it needs to enter a waiting state; if it needs to enter a waiting state, the thread stores its thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule; wherein the global lock is used to indicate idle thread waiting units in the waiting queue, one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread. This application improves system processing efficiency.

Description

Technical Field

[0001] This application relates to the field of databases, specifically to a thread management method, apparatus, and related devices. Background Technology

[0002] In database management systems, mutexes are a crucial synchronization mechanism ensuring safe access to shared resources by concurrent threads. They involve three processes: locking, waiting, and unlocking. Specifically, if multiple threads concurrently request the same mutex, and the mutex is not currently held, it is acquired immediately. If the mutex is already held, the threads enter a waiting queue to be awakened. When the mutex is released, all threads waiting for the mutex in the waiting queue are awakened to re-compete for the lock resource.

[0003] However, the system processing efficiency of the above processes still needs to be improved. Summary of the Invention

[0004] In view of this, embodiments of this application provide a thread management method, apparatus, and related devices to improve system processing efficiency.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide a thread management method, including: When multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in the first state, which indicates that the mutex lock has been occupied. If the mutex is determined to be in the first state, the thread determines whether it needs to enter the waiting state. If a thread determines that it needs to enter a waiting state, it stores its own thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule. The global lock is used to indicate the idle thread waiting unit in the waiting queue, and one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread.

[0007] Optionally, the step of a thread determining whether it needs to enter a waiting state includes: Within a preset time period, the thread continuously checks whether the mutex is in its first state. If the mutex lock remains in the first state for a preset time, then the time slice occupied by the thread is released. When the thread is selected for execution again by the operating system scheduler, it is checked again whether the mutex is in the first state. If the mutex is in the first state, the thread determines that it needs to enter the waiting state.

[0008] Optionally, the step of storing its own thread information into the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit includes: Acquire the global lock of the waiting queue; Based on the global lock, the target thread waiting unit is determined, and the unit lock corresponding to the target thread waiting unit is acquired; Based on the unit lock, the thread information of the thread itself is stored in the target thread waiting unit.

[0009] Optionally, the step of each thread concurrently determining whether the mutex is in the first state specifically includes: Each thread concurrently determines whether the mutex is in the first state based on atomic operations.

[0010] Optionally, if it is determined that the mutex is not in the first state, then one of the multiple threads occupies the mutex and modifies the mutex to the first state.

[0011] Optionally, the step of selecting a thread to wake up from the waiting queue based on preset rules includes: Based on the order of threads in the waiting queue, the thread at the first position in the waiting queue is selected for waking up.

[0012] Secondly, embodiments of this application provide a thread management device, including: The first judgment module is used to determine whether the mutex is in a first state when multiple threads concurrently request the same mutex. The first state is used to indicate that the mutex has been occupied. The second judgment module is used to determine whether a thread needs to enter a waiting state when the mutex lock is in the first state. The storage module is used to store the thread's own thread information into the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit when it determines that it needs to enter a waiting state. When the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule. The global lock is used to indicate the idle thread waiting units in the waiting queue, and one thread waiting unit corresponds to one unit lock. One thread waiting unit stores the thread information of one thread.

[0013] Thirdly, embodiments of this application provide an electronic device, including at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the thread management method as described in the first aspect above.

[0014] Fourthly, embodiments of this application provide a storage medium that stores one or more computer-executable instructions, which, when executed, implement the thread management method described in the first aspect above.

[0015] Fifthly, embodiments of this application provide a computer program product including one or more computer-executable instructions, wherein when the one or more computer-executable instructions are executed, the thread management method described in the first aspect above is implemented.

[0016] This application provides a thread management method, apparatus, and related devices. The method includes: when multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in a first state, where the first state indicates that the mutex lock is occupied; if the mutex lock is in the first state, the thread determines whether it needs to enter a waiting state; if it needs to enter a waiting state, the thread stores its thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule; wherein the global lock is used to indicate the idle thread waiting units in the waiting queue, one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread.

[0017] As can be seen, the thread management method provided in this application quickly allocates idle thread waiting units in the waiting queue through the global lock of the waiting queue. The unit lock is used for subsequent exclusive writing to the thread waiting unit. The unit lock has a smaller granularity, so that the exclusive writing of the thread only affects a single thread waiting unit, avoiding blocking other threads from allocating idle thread waiting units. This avoids serious lock contention in high-concurrency scenarios, and the problem of multiple threads being forced to queue and wait when competing for the global lock at the same time, thereby improving the system processing efficiency.

[0018] Furthermore, when the mutex is released, a thread is selected from the waiting queue to be woken up based on a preset rule. This avoids the surge in thread context switching caused by waking up all threads waiting for the mutex in the waiting queue, reducing the overhead of the system's core computing resources and further improving the system's processing efficiency. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 This is an optional flowchart of the thread management method provided in the embodiments of this application; Figure 2 This is an optional flowchart of step S200 provided in the embodiments of this application; Figure 3 This is an optional flowchart of step S300 provided in the embodiments of this application; Figure 4 This is a schematic diagram of an optional structure of the thread management device provided in the embodiments of this application; Figure 5 This is an optional block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] As described in the background section, in database management systems, mutexes are a crucial synchronization mechanism ensuring safe access to shared resources by concurrent threads. This involves three processes: locking, waiting, and unlocking. Specifically, if multiple threads concurrently request the same mutex, and if the mutex is not currently held, it is acquired immediately. If the mutex is already held, the threads enter a waiting queue to be awakened. When the mutex is released, all threads waiting for the mutex in the waiting queue are awakened to re-compete for the lock resource.

[0023] In an optional implementation, MySQL's InnoDB storage engine can implement an internal mutex lock using `event_mutex_t`, which relies on `pthread_mutex_t` from the POSIX Threads library (pthread). For ease of understanding, taking the implementation of an internal mutex lock using `event_mutex_t` as an example, the specific locking, waiting, and unlocking process is as follows: Locking process: When multiple threads concurrently request the same mutex (event_mutex_t), the threads first attempt to acquire the mutex directly. If the mutex is not currently occupied, the lock is acquired successfully immediately.

[0024] Waiting Process: If the mutex is already held by another thread, the current thread will not block immediately but will enter a spin-waiting phase, continuously attempting to acquire the mutex by repeatedly checking its state. If the mutex is not released after a spin timeout, the thread will call `sched_yield()` (or a similar mechanism) to voluntarily relinquish its time slice, allowing other threads to run and avoiding prolonged idle time that consumes core system computing resources. After the thread relinquishes its time slice, the scheduler will select another thread to run. When the thread is scheduled again, it will re-attempt to acquire the mutex. If the mutex is still held, the thread will eventually enter a waiting queue to be woken up. In the InnoDB storage engine, `event_mutex_t` manages all threads that have entered a waiting state due to their inability to acquire the mutex through a global data structure `sync_array` (i.e., the waiting queue). Specifically, the process first acquires the global lock of `sync_array` to ensure exclusive access to the waiting queue. Then, it writes the thread information of the current waiting thread into an idle `sync_cell_t` unit. After writing, it releases the global lock of `sync_array`, allowing other threads to concurrently operate on `sync_array`. Here, `sync_array` is a global object composed of multiple `sync_cell_t` units. Each `sync_cell_t` unit independently stores the information of a waiting thread.

[0025] Unlocking process: When the mutex is released, a condition variable broadcast wake-up (pthread_cond_broadcast()) is used to wake up all threads in the sync_array that are waiting for the mutex, so that they can compete for the lock resource again. Here, broadcast wake-up refers to the strategy of notifying all waiting threads to continue execution when the condition variable is activated.

[0026] However, the inventors believe that the above-mentioned mutex lock waiting and wake-up mechanism has the following problems in high-concurrency scenarios: (1) In the current process of managing all waiting threads through a waiting queue, any access to the waiting queue (e.g., adding, removing, or traversing waiting threads) must first acquire the global lock of the waiting queue. This design will cause serious lock contention in high-concurrency scenarios. When multiple threads compete for the global lock at the same time, they are forced to queue up and wait, forming a new performance bottleneck and severely limiting the scalability and extensibility of the system.

[0027] (2) In scenarios with intense lock contention, when a large number of threads are queuing to wait for a mutex, the release of the mutex will trigger a broadcast wake-up to wake up all waiting threads. However, these awakened threads will quickly re-enter the waiting queue because they cannot immediately preempt the lock resource, forming a frequent cycle of "wake-up-wait", which leads to a surge in the number of thread context switches and significantly increases the overhead of the system's core computing resources.

[0028] In view of this, embodiments of this application provide a thread management method, apparatus, and related devices. The method includes: when multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in a first state, where the first state indicates that the mutex lock is occupied; if the mutex lock is in the first state, the thread determines whether it needs to enter a waiting state; if it determines that it needs to enter a waiting state, the thread stores its thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule; wherein the global lock is used to indicate the idle thread waiting units in the waiting queue, and one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread.

[0029] As can be seen, the thread management method provided in this application quickly allocates idle thread waiting units in the waiting queue through the global lock of the waiting queue. The unit lock is used for subsequent exclusive writing to the thread waiting unit. The unit lock has a smaller granularity, so that the exclusive writing of the thread only affects a single thread waiting unit, avoiding blocking other threads from allocating idle thread waiting units. This avoids serious lock contention in high-concurrency scenarios, and the problem of multiple threads being forced to queue and wait when competing for the global lock at the same time, thereby improving the system processing efficiency.

[0030] Furthermore, when the mutex is released, a thread is selected from the waiting queue to be woken up based on a preset rule. This avoids the surge in thread context switching caused by waking up all threads waiting for the mutex in the waiting queue, reducing the overhead of the system's core computing resources and further improving the system's processing efficiency.

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

[0032] refer to Figure 1 , Figure 1 This is a schematic diagram of an optional flow of the thread management method provided in an embodiment of this application. For example... Figure 1 As shown, the method may include the following steps: Step S100: When multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in the first state, whereby the first state indicates that the mutex lock has been occupied.

[0033] If the mutex is determined to be in the first state, then step S200 is executed, and the thread determines whether it needs to enter the waiting state; if the mutex is determined not to be in the first state, then one of the multiple threads occupies the mutex and modifies the mutex to the first state.

[0034] When multiple threads simultaneously attempt to acquire the same mutex, each thread independently checks the mutex's current state to determine if it is in the first state, which indicates the mutex is already occupied. If the mutex is in the first state, the thread decides whether it needs to enter a waiting state; if it is not in the first state, one thread acquires the mutex and sets it to the first state. The thread that successfully acquires the mutex can execute the critical section code, while other threads further determine whether they need to enter a waiting state. This mutex acquisition mechanism in multi-threaded concurrency scenarios ensures that only one thread can hold the mutex at a time, avoiding data races.

[0035] The step of each thread concurrently determining whether the mutex is in its first state specifically involves each thread concurrently determining whether the mutex is in its first state based on an atomic operation. An atomic operation is an indivisible and uninterrupted operation that, once started, runs continuously until completion without being interrupted by other operations or events. Logically, an atomic operation is a single unit and cannot be broken down into smaller steps. In the implementation of a mutex, atomic operations ensure that the checking and modification of the mutex state are indivisible. For example, when a thread attempts to acquire a mutex, it executes an atomic operation to check the mutex's state. If the mutex is not in its first state (i.e., the mutex is not occupied), the thread modifies the mutex's state to the first state (i.e., the mutex is occupied) and continues execution.

[0036] In a multithreaded environment, atomic operations can prevent data races. For example, in a mutex implementation, even if multiple threads simultaneously check that the mutex is not in the first state, due to the exclusivity of atomic operations, only the first thread to execute the atomic operation can successfully acquire the mutex and change it to the first state. The atomic operations of other threads will fail because the state of the mutex has changed.

[0037] refer to Figure 1 Continue executing step S200, where the thread determines whether it needs to enter a waiting state.

[0038] In the optional implementation, refer to Figure 2 The exemplary schematic diagram of step S200 shows that step S200, in which the thread determines whether it needs to enter a waiting state, may include: Step S201: Within a preset time period, the thread cyclically determines whether the mutex is in the first state.

[0039] When a thread attempts to acquire a mutex, if it finds the mutex in its first state (i.e., the mutex is already occupied), it enters a spin-waiting loop. Within a preset time, the thread repeatedly checks whether the mutex is in its first state. If the mutex can be released in a very short time, spin-waiting avoids the additional overhead of thread switching. The preset time is typically short (e.g., a few microseconds to a few milliseconds) to prevent prolonged idle time from wasting core system computing resources.

[0040] In this way, threads can quickly resume execution when lock contention is not intense, thereby improving the overall system performance. However, if the mutex lock remains in the first state for a preset time, the thread will execute step S202, relinquishing the time slice it occupies, and instead relying on the operating system's scheduling mechanism to balance resource utilization and response efficiency.

[0041] Step S202: Release the time slice occupied by the thread.

[0042] If the mutex lock remains in the first state for a preset time, the thread will actively call the scheduler interface (e.g., sched_yield() or pthread_yield()) to relinquish the time slice it occupies, allowing other threads to run. This avoids wasting core computing resources due to spin waiting and reduces the impact of thread contention on system performance.

[0043] It is understandable that after a thread relinquishes its time slice, it does not enter the waiting queue and may still be rescheduled by the operating system scheduler in the short term.

[0044] Step S203: When the thread is selected for execution again by the operating system scheduler, it is determined again whether the mutex lock is in the first state.

[0045] When a thread is reselected for execution by the operating system scheduler, the state of the mutex is checked again. If the mutex is in the first state, step S204 is executed, and the thread determines that it needs to enter a waiting state. If the mutex is not in the first state, the thread can attempt to acquire the mutex through an atomic operation.

[0046] In step S204, the thread determines that it needs to enter a waiting state.

[0047] If a thread fails to acquire the mutex lock after multiple attempts, the thread will enter a waiting state.

[0048] Continue to refer to Figure 1 If it determines that it needs to enter a waiting state, then execute step S300. The thread stores its own thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit.

[0049] The global lock is used to indicate the idle thread waiting unit in the waiting queue, and one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread.

[0050] This application separates the global lock from the unit lock. The global lock is only used to quickly allocate idle thread waiting units in the waiting queue, while the unit lock is used for subsequent exclusive writing to the target thread waiting unit. The unit lock has a smaller granularity and may be held for a longer time, but it only affects a single thread waiting unit, avoiding blocking other threads from allocating idle thread waiting units. This avoids serious lock contention in high-concurrency scenarios, preventing multiple threads from being forced to queue and wait when competing for the global lock at the same time, thereby improving system processing efficiency.

[0051] In the optional implementation, refer to Figure 3 The exemplary schematic diagram of step S300 shows an optional process. In step S300, the thread stores its own thread information into the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit. This step may include: Step S301: Acquire the global lock of the waiting queue.

[0052] The thread first attempts to acquire a global lock on the waiting queue. This global lock is used to indicate the idle waiting units in the queue, protect the queue's metadata (e.g., a list of idle units, head and tail pointers), and prevent multiple threads from modifying the queue's structure simultaneously. The global lock has a relatively large granularity and a short holding time; it is only used to locate idle waiting units.

[0053] Step S302: Based on the global lock, determine the target thread waiting unit and acquire the unit lock corresponding to the target thread waiting unit.

[0054] While a thread holds a global lock, the thread can traverse the waiting queue, determine the target thread waiting unit (i.e., an unoccupied thread waiting unit), acquire the unit lock corresponding to the target thread waiting unit, and occupy the target thread waiting unit to ensure exclusive writing to the target thread waiting unit.

[0055] Step S303: Based on the unit lock, store its own thread information to the target thread waiting unit.

[0056] After acquiring the unit lock of the target thread's waiting unit, the thread can write its own thread information (e.g., thread ID, priority, wake-up condition, etc.) into the target thread's waiting unit. After writing, the thread releases the unit lock, allowing other threads to operate on the target thread's waiting unit (e.g., waking up the thread when the mutex is released).

[0057] In optional implementations, the unit lock can be not only a general-purpose mutex like `Pthread_mutex`, but also other low-overhead synchronization primitives that support reentrancy or preemption, such as user-space spin locks, Ticket Locks or MCS Locks optimized for NUMA architectures, and hardware atomic instructions. Ticket Lock is a spin lock that achieves fair lock acquisition based on a "ticket" mechanism. A thread determines whether to acquire the lock by comparing its own queue number with the number of the currently being served thread. If they match, the thread acquires the lock and enters the critical section; otherwise, it spins and waits. MCS Lock is a spin lock based on a linked list structure. Each thread spins on a local variable, and a waiting queue is maintained through linked list nodes. The predecessor thread notifies the successor thread to end the spin.

[0058] Furthermore, the granularity of the unit lock can also be dynamically adjusted and optimized. Specifically, in addition to allocating a unit lock individually to each thread waiting unit, multiple adjacent thread waiting units can be aggregated into a synchronization block based on actual access patterns, such as the strength of thread concurrency and the distribution characteristics of data locality, and a single lock can be used to protect this synchronization block. Through this dynamic adjustment strategy, a flexible and effective balance can be achieved between memory overhead, parallelism, and conflict probability.

[0059] Based on the global lock of the waiting queue and the unit lock of the thread waiting unit, the thread stores its own thread information in the corresponding thread waiting unit. When the mutex is released, a thread is selected from the waiting queue to be woken up according to a preset rule. This avoids the surge in thread context switching caused by waking up all threads waiting for the mutex in the waiting queue, reduces the overhead of the system's core computing resources, and further improves the system's processing efficiency.

[0060] In one optional implementation, the step of selecting a thread to wake up from the waiting queue based on a preset rule may include: selecting the thread at the first position in the waiting queue based on the thread's order in the waiting queue. In other optional implementations, a preset number of eligible threads may be woken up at once, or the next thread to be woken up may be dynamically selected based on thread priority.

[0061] In addition, the wake-up behavior can be dynamically adjusted based on the following conditions: (1) By monitoring system load metrics (e.g., utilization of core computing resources or task queue length), limit the number of wake-up threads when the system is under high load to avoid resource contention and performance degradation caused by excessive wake-up.

[0062] (2) Based on the access frequency characteristics of the resource being waited for, if it is detected that the resource has been accessed frequently recently, the thread wake-up time should be appropriately delayed to reduce the probability of conflict caused by multi-threaded concurrent operations.

[0063] (3) Optimize the wake-up order based on the analysis of thread history behavior, such as waking up threads that have been waiting for a long time to prevent starvation, or ensuring that each thread gets an equal opportunity to execute through fair strategies such as round-robin scheduling.

[0064] As can be seen, the thread management method provided in this application quickly allocates idle thread waiting units in the waiting queue through the global lock of the waiting queue. The unit lock is used for subsequent exclusive writing to the thread waiting unit. The unit lock has a smaller granularity, so that the exclusive writing of the thread only affects a single thread waiting unit, avoiding blocking other threads from allocating idle thread waiting units. This avoids serious lock contention in high-concurrency scenarios, and the problem of multiple threads being forced to queue and wait when competing for the global lock at the same time, thereby improving the system processing efficiency.

[0065] Furthermore, when the mutex is released, a thread is selected from the waiting queue to be woken up based on a preset rule. This avoids the surge in thread context switching caused by waking up all threads waiting for the mutex in the waiting queue, reducing the overhead of the system's core computing resources and further improving the system's processing efficiency.

[0066] The thread management device provided in the embodiments of this application will be described below. The thread management device described below can be considered as a software or hardware functional module required to implement the thread management method provided in the embodiments of this application. The content of the thread management device described below can be referred to in correspondence with the content of the method described above.

[0067] In an optional implementation, Figure 4An exemplary schematic diagram of an optional structure of the thread management device provided in an embodiment of this application is shown, such as... Figure 4 As shown, the thread management device may include: The first judgment module 11 is used to determine whether the mutex is in a first state when multiple threads concurrently request the same mutex. The first state is used to indicate that the mutex has been occupied. The second judgment module 12 is used to determine whether a thread needs to enter a waiting state when the mutex lock is in the first state. The storage module 13 is used to, when a thread determines that it needs to enter a waiting state, store its own thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule; wherein, the global lock is used to indicate the idle thread waiting units in the waiting queue, one thread waiting unit corresponds to one unit lock; one thread waiting unit stores the thread information of one thread.

[0068] Optionally, the second judgment module 12 is used to determine whether a thread needs to enter a waiting state when the mutex is in the first state, including: Within a preset time period, the thread continuously checks whether the mutex is in its first state. If the mutex lock remains in the first state for a preset time, then the time slice occupied by the thread is released. When the thread is selected for execution again by the operating system scheduler, it is checked again whether the mutex is in the first state. If the mutex is in the first state, the thread determines that it needs to enter the waiting state.

[0069] Optionally, the storage module 13 is used to, when determining that it needs to enter a waiting state, store its own thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, including: Acquire the global lock of the waiting queue; Based on the global lock, the target thread waiting unit is determined, and the unit lock corresponding to the target thread waiting unit is acquired; Based on the unit lock, the thread information of the thread itself is stored in the target thread waiting unit.

[0070] Optionally, the first judgment module 11 is used to determine whether the mutex is in the first state when multiple threads concurrently request the same mutex, specifically: Each thread concurrently determines whether the mutex is in the first state based on atomic operations.

[0071] Optionally, if it is determined that the mutex is not in the first state, then one of the multiple threads occupies the mutex and modifies the mutex to the first state.

[0072] Optionally, the step of selecting a thread to wake up from the waiting queue based on preset rules includes: Based on the order of threads in the waiting queue, the thread at the first position in the waiting queue is selected for waking up.

[0073] As can be seen, the thread management device provided in this application embodiment quickly allocates idle thread waiting units in the waiting queue through the global lock of the waiting queue. The unit lock is used for subsequent exclusive writing to the thread waiting unit. The unit lock has a smaller granularity, so that the exclusive writing of the thread only affects a single thread waiting unit, avoiding blocking other threads from allocating idle thread waiting units. This avoids serious lock contention in high-concurrency scenarios, and the problem of multiple threads being forced to queue and wait when competing for the global lock at the same time, thereby improving the system processing efficiency.

[0074] Furthermore, when the mutex is released, a thread is selected from the waiting queue to be woken up based on a preset rule. This avoids the surge in thread context switching caused by waking up all threads waiting for the mutex in the waiting queue, reducing the overhead of the system's core computing resources and further improving the system's processing efficiency.

[0075] This application also provides an electronic device that may include at least one memory and at least one processor. The memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the thread management method described above.

[0076] As an optional implementation, refer to Figure 5 , Figure 5 This is an optional block diagram of the electronic device provided in the embodiments of this application. For example... Figure 5 As shown, the electronic device may include: at least one processor 21, at least one communication interface 22, at least one instruction memory 23 and at least one communication bus 24.

[0077] In this embodiment, the number of processor 21, communication interface 22, instruction memory 23 and communication bus 24 is at least one, and processor 21, communication interface 22 and instruction memory 23 communicate with each other through communication bus 24.

[0078] Optionally, the processor 21 may be a CPU (Central Processing Unit), GPU (Graphics Processing Unit), NPU (Neural-network Processing Unit), FPGA (Field Programmable Gate Array), TPU (Tensor Processing Unit), AI chip, ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0079] Optionally, the communication interface 22 can be an interface for a communication module used for network communication.

[0080] Instruction memory 23 may include high-speed RAM and may also include non-volatile memory, such as at least one disk storage device. Instruction memory 23 stores one or more computer-executable instructions, which processor 21 invokes to execute the thread management method described above.

[0081] This application also provides a storage medium that stores one or more computer-executable instructions, which, when executed, implement the thread management method described above.

[0082] This application also provides a computer program product that may include one or more computer-executable instructions, which, when executed, implement the thread management method described above.

[0083] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0084] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A thread management method, characterized in that, include: When multiple threads concurrently request the same mutex lock, each thread concurrently determines whether the mutex lock is in the first state, which indicates that the mutex lock has been occupied. If the mutex is determined to be in the first state, the thread determines whether it needs to enter the waiting state. If a thread determines that it needs to enter a waiting state, it stores its own thread information in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit, so that when the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule. The global lock is used to indicate the idle thread waiting unit in the waiting queue, and one thread waiting unit corresponds to one unit lock; Each thread waiting unit stores the thread information of one thread.

2. The thread management method according to claim 1, characterized in that, The step of a thread determining whether it needs to enter a waiting state includes: Within a preset time period, the thread continuously checks whether the mutex is in its first state. If the mutex lock remains in the first state for a preset time, then the time slice occupied by the thread is released. When the thread is selected for execution again by the operating system scheduler, it is checked again whether the mutex is in the first state. If the mutex is in the first state, the thread determines that it needs to enter the waiting state.

3. The thread management method according to claim 1, characterized in that, The step of a thread storing its own thread information into the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit includes: Acquire the global lock of the waiting queue; Based on the global lock, the target thread waiting unit is determined, and the unit lock corresponding to the target thread waiting unit is acquired; Based on the unit lock, the thread information of the thread itself is stored in the target thread waiting unit.

4. The thread management method according to claim 1, characterized in that, The step of each thread concurrently determining whether the mutex is in the first state is as follows: Each thread concurrently determines whether the mutex is in the first state based on atomic operations.

5. The thread management method according to claim 1, characterized in that, If it is determined that the mutex is not in the first state, then one of the multiple threads will occupy the mutex and modify the mutex to the first state.

6. The thread management method according to claim 1, characterized in that, The step of selecting a thread to wake up from the waiting queue based on preset rules includes: Based on the order of threads in the waiting queue, the thread at the first position in the waiting queue is selected for waking up.

7. A thread management device, characterized in that, include: The first judgment module is used to determine whether the mutex is in a first state when multiple threads concurrently request the same mutex. The first state is used to indicate that the mutex has been occupied. The second judgment module is used to determine whether a thread needs to enter a waiting state when the mutex lock is in the first state. The storage module is used to store the thread information of a thread in the corresponding thread waiting unit based on the global lock of the waiting queue and the unit lock of the thread waiting unit when it determines that it needs to enter the waiting state. When the mutex lock is released, a thread is selected from the waiting queue to be woken up based on a preset rule. The global lock is used to indicate the idle thread waiting units in the waiting queue, and one thread waiting unit corresponds to one unit lock. Each thread waiting unit stores the thread information of one thread.

8. An electronic device, characterized in that, It includes at least one memory and at least one processor, the memory storing one or more computer-executable instructions, and the processor invoking the one or more computer-executable instructions to execute the thread management method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores one or more computer-executable instructions, which, when executed, implement the thread management method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes one or more computer-executable instructions, which, when executed, implement the thread management method as described in any one of claims 1 to 6.

Images