Node-aware optimistic spin queue lock processing method and apparatus
By dividing the OSQ lock into multiple sub-queues according to NUMA nodes and adopting a hash table and pseudo-random lock transfer mechanism, the performance problem caused by OSQ locks under NUMA architecture is solved, achieving more efficient lock management and system performance improvement.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- UNIONTECH SOFTWARE TECH CO LTD
- Filing Date
- 2025-06-27
- Publication Date
- 2026-05-29
AI Technical Summary
In NUMA architecture, the global queue design of traditional optimistic spin queue locks (OSQ locks) leads to high latency and high cache miss rate, which affects system performance.
The OSQ lock is divided into multiple sub-queues based on NUMA nodes, and the queues are dynamically managed through a hash table. A pseudo-random lock transfer mechanism and probability parameters are introduced to dynamically adjust the probability of lock transfer in order to balance fairness and performance.
It reduces cache invalidation and high latency issues caused by cross-node memory access, lowers memory usage, solves the queue starvation problem, and improves system performance.
Smart Images
Figure CN120849146B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, specifically to a node-aware optimistic spin queue lock processing method and apparatus. Background Technology
[0002] In modern multi-core processor systems, Non-Uniform Memory Access (NUMA) architecture has become the mainstream design. (Reference) Figure 6 NUMA architecture divides the processor and memory into multiple nodes. The CPU (Central Processing Unit) within each node accesses local memory most quickly, while accessing memory on remote nodes introduces significant latency. This architectural characteristic makes the synchronization mechanisms designed for UMA (Uniform Memory Access) architectures face severe performance challenges in NUMA environments.
[0003] Optimistic Spinning Queue locks (OSQ locks) are an optimization mechanism in the Linux kernel designed for mutexes and read-write semaphores. The core idea is that when a lock is acquired, waiting threads do not immediately enter a sleep state, but instead spin for a limited time. This mechanism manages the spinning threads by maintaining a waiting queue (OSQ queue), effectively reducing unnecessary context switching overhead.
[0004] In NUMA architectures, cross-node memory access latency is significantly higher than local node access. The global queue design of traditional OSQ locks leads to frequent cross-node cache line invalidations during lock transfer, causing performance degradation. Current OSQ locks manage spinning processes through a single queue, requiring cross-node modification of the next CPU's locked flag during lock transfer, resulting in high latency and a high LLC Miss (High Last-Level Cache Miss Rate). Summary of the Invention
[0005] This application provides a node-aware optimistic spin queue lock processing method and apparatus.
[0006] Firstly, this application provides a node-aware optimistic spin queue lock processing method applied to a NUMA architecture system. The system manages multiple optimistic spin queue locks, each corresponding one-to-one with multiple NUMA nodes. The method includes: the current thread determining whether a corresponding NUMA node queue already exists on the local NUMA node by looking up a hash table; if it already exists, acquiring the optimistic spin queue lock through the NUMA node queue; determining whether to release the optimistic spin queue lock; calculating a probability parameter using a pseudo-random algorithm, and determining whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes based on whether the probability parameter exceeds a preset value.
[0007] In some optional implementations, the current thread determines whether a corresponding NUMA node queue already exists for the local NUMA node by looking up a hash table, including: the current thread obtaining the identifier of the local NUMA node where the current CPU is located; obtaining the optimistic spin queue lock instance address based on the obtained local NUMA node identifier; generating a hash key based on the obtained optimistic spin queue lock instance address; and determining whether a corresponding NUMA node queue already exists for the local NUMA node by looking up a hash table.
[0008] In some optional implementations, the step of acquiring the optimistic spin queue lock through the NUMA node queue includes: adding the local optimistic spin queue lock node to the NUMA node queue; waiting for the predecessor lock-holding CPU to pass the optimistic spin queue lock; and determining the acquisition of the optimistic spin queue lock through cache synchronization.
[0009] In some optional implementations, after the current thread determines whether a corresponding NUMA node queue already exists for the local NUMA node by looking up a hash table, the method further includes: if it does not exist, creating a NUMA node queue corresponding to the local NUMA node, adding the local optimistic spin queue lock node to the NUMA node queue, and directly acquiring the optimistic spin queue lock.
[0010] In some optional implementations, after determining that the optimistic spin queue lock is to be released, the method further includes: determining whether there is a successor optimistic spin queue lock node in the NUMA node queue; if so, performing the step of calculating the probability parameters using a pseudo-random algorithm.
[0011] In some optional implementations, after determining whether the NUMA node queue has a successor optimistic spin queue lock node, the method further includes: if it does not exist, checking whether there is a waiting thread in the remote NUMA node queue corresponding to other NUMA nodes; if it does exist, passing the optimistic spin queue lock to the waiting thread of the remote NUMA node queue.
[0012] In some optional implementations, after checking whether there are waiting threads in the remote NUMA node queues corresponding to other NUMA nodes, the method further includes: if there are no waiting threads, then exiting directly.
[0013] Secondly, this application provides a node-aware optimistic spin queue lock processing method and apparatus, applied to a NUMA architecture system. The system manages multiple optimistic spin queue locks, each corresponding one-to-one with multiple NUMA nodes. The apparatus includes: a lookup module configured to enable the current thread to determine whether a corresponding NUMA node queue already exists on the local NUMA node by looking up a hash table; an acquisition module configured to acquire the optimistic spin queue lock through the NUMA node queue if the lookup module determines that the queue already exists; a determination module configured to determine whether to release the optimistic spin queue lock; and a calculation module configured to calculate a probability parameter using a pseudo-random algorithm, and determine whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes based on whether the probability parameter exceeds a preset value.
[0014] Thirdly, this application provides a computer device, including: one or more processors; and a storage device having one or more programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform the method as described in the first aspect.
[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by one or more processors, implements the method described in the first aspect.
[0016] To address the performance degradation issue caused by the global single-queue mechanism of traditional OSQ locks in NUMA architectures, this application proposes a node-aware optimistic spin queue lock processing method and apparatus. The beneficial effects achieved by adopting the above technical solution include, but are not limited to:
[0017] 1) Divide the traditional global OSQ lock queue into multiple sub-queues (i.e. multiple NUMA node queues) according to NUMA nodes, which can reduce cache invalidation and high latency issues caused by cross-node memory access.
[0018] 2) Dynamically manage queues using hash tables to avoid a surge in memory usage due to an increase in the number of queues (related to the number of NUMA nodes) (for example, only 4MB of static space is required).
[0019] 3) Solve the starvation problem of a queue by using a pseudo-random lock passing mechanism. When the lock is released, a pseudo-random algorithm is used to determine whether to pass the lock to the successor thread of the local NUMA node or to the thread of another NUMA node across nodes.
[0020] 4) Introduce the probability parameter INTRA_NODE_HANDOFF_PROB_ARG (node-internal lock propagation probability parameter) to dynamically adjust the probability of local and cross-node propagation, balancing fairness and performance. Attached Figure Description
[0021] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings:
[0022] Figure 1 This is a sequence diagram of the traditional OSQ lock workflow;
[0023] Figure 2 This is a timing diagram of a node-aware optimistic spin queue lock processing method under a NUMA architecture according to an embodiment of this application;
[0024] Figure 3 This is a flowchart of an embodiment of the node-aware optimistic spin queue lock processing method of this application;
[0025] Figure 4 This is a schematic diagram of the structure of a node-aware optimistic spin queue lock processing device according to an embodiment of this application;
[0026] Figure 5 This is a schematic diagram of the structure of a computer device for implementing a server according to an embodiment of this application;
[0027] Figure 6 This is a schematic diagram showing the layout relationship between the CPU and memory under the NUMA architecture. Detailed Implementation
[0028] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.
[0029] refer to Figure 1 , Figure 1 This is a sequence diagram of the traditional OSQ lock workflow. The OSQ lock is a queued spin lock mechanism that allows threads waiting for the lock to spin briefly before being woken up. This avoids the sleep / wake-up overhead when the lock is quickly released, thereby reducing contention and false sharing and improving efficiency.
[0030] like Figure 1 As shown, the traditional OSQ lock workflow includes the following steps:
[0031] Existing OSQ lock workflow:
[0032] Step 1. Begin acquiring the lock.
[0033] The current thread on the CPU wants to enter the critical section and calls the OSQ lock interface to try to acquire the lock.
[0034] Step 2. Create a local osq_node (OSQ node).
[0035] Each CPU creates and manages a local osq_node (usually a pre-allocated, CPU-unique structure), and the current thread is ready to use the osq_node to indicate that it is waiting to acquire the lock.
[0036] Step 3. The atom adds the local node to the tail of the lock queue.
[0037] Atomic swap operations are used to link local osq_node nodes to the tail of the lock queue, establishing a FIFO (First Input First Output) queuing structure. This lock queue is a global queue.
[0038] Step 4. Is it the first node?
[0039] If the return value is NULL (meaning no one held the lock initially), it means the current thread is the first thread to join the lock queue, and the local osq_node is the first node, so it can directly acquire the lock, then jump to step 5; otherwise, the local osq_node is not the first node, proceed to the next step of waiting, and jump to step 6.
[0040] Step 5. Acquire the lock directly and enter the critical section.
[0041] The current thread becomes the lock holder and can immediately enter the critical section to execute critical code without waiting.
[0042] Step 6. Wait for the front drive holding the lock CPU to pass the lock.
[0043] If the current thread is not the first one in the queue, it will wait for the previous node to hold the lock and then pass the lock to itself.
[0044] Step 7. Write to my osq_node when the predecessor releases the lock.
[0045] When the current lock holder releases the lock, it will actively access the current thread's osq_node and write the "lock has been passed" flag.
[0046] Step 8. My CPU learns that it has acquired the lock through cache synchronization.
[0047] The current thread is spinning and waiting, observing only the flag bits in its local osq_node to obtain the flag information; because the predecessor modified this value, the local CPU's cache line is invalidated and reloaded, thus discovering that the lock has been passed.
[0048] Step 9. Spin on the mutex lock to enter the critical section.
[0049] Once the current thread discovers that it has acquired the lock, it immediately enters the critical section to execute the critical task.
[0050] Step 10. Acquire the mutex lock, the critical section ends, and prepare to release the OSQ lock.
[0051] After the current thread completes its task, it prepares to release the lock and pass it to the next waiting thread (if any).
[0052] Step 11. Check if there is a successor node.
[0053] The osq_node stores information about the successor node in the chain (i.e., the next person in the queue); the current thread reads this field to determine if there are any waiting nodes.
[0054] Step 12. Write to the successor osq_node and pass the lock.
[0055] If a successor node exists, the current thread writes a flag message "lock passed" to that node, notifying it that it has acquired the lock. The successor thread will detect the lock's arrival while spinning due to cache synchronization.
[0056] Step 13. The atom emptys the lock queue, completing the release.
[0057] If there is no successor node, the current thread sets the global queue of the lock to NULL (empty) through an atomic operation, indicating that the lock has been completely released and the queue is empty.
[0058] refer to Figure 2 , Figure 2 This is a timing diagram of a node-aware optimistic spin queue lock (OSQ lock) processing method under a NUMA architecture according to an embodiment of this application.
[0059] The method in this application embodiment, compared to the traditional OSQ lock workflow, mainly includes the following improvements:
[0060] ① NUMA node queue partitioning: The traditional global OSQ lock queue is divided into multiple sub-queues according to NUMA nodes. Each NUMA node corresponds to a sub-queue (which can be called a NUMA node queue), reducing cache invalidation and high latency issues caused by cross-node memory access.
[0061] ② Dynamic Hash Table Management: Multiple sub-queues are dynamically managed using hash tables to avoid a surge in memory usage due to an increase in the number of queues (for example, only 4MB of static space is required).
[0062] ③ Pseudo-random lock passing mechanism: This solves the problem of a queue starvation. When the lock is released, a pseudo-random algorithm is used to determine whether to pass the lock to the successor thread of the local NUMA node or to the thread of the corresponding sub-queue of another NUMA node.
[0063] ④ Dynamic parameter adjustment: Introducing the probability parameter INTRA_NODE_HANDOFF_PROB_ARG (node-internal lock transfer probability parameter) to dynamically adjust the probability of local and cross-node transfer, balancing fairness and performance.
[0064] refer to Figure 2 The workflow of the node-aware optimistic spin queue lock (OSQ lock) processing method under the NUMA architecture of this application includes the following steps:
[0065] Step 1. Begin acquiring the lock.
[0066] The current thread on the CPU wants to enter the critical section and calls the OSQ lock interface to try to acquire the lock.
[0067] Step 2. Obtain the NUMA node ID (identifier) where the current CPU is located.
[0068] Step 3. Generate a hash key based on the OSQ instance address in the mutex / rw_semaphore.
[0069] Step 4. Find the queue position in the hash table based on the hash key. The hash table is used to manage multiple NUMA node queues. Each NUMA node queue is a sub-queue, corresponding to one NUMA node.
[0070] Step 5. Determine if the current NUMA node has a queue. If yes, proceed to step 6; otherwise, proceed to step 7.
[0071] Step 6. If a queue exists for the current NUMA node, the current thread adds its local osq_node to the tail of the queue. Specifically, an atomic swap operation can be used to link the local osq_node to the tail of the current NUMA node queue, establishing a FIFO (First-In-First-Out) queuing structure. Then, proceed to step 10.
[0072] Step 7. Check if all NUMA node queues are empty. If so, the current thread is the first thread to join the queue. Proceed to Step 8.
[0073] Step 8. Create a new NUMA node queue and add the local osq_node, then proceed to step 9.
[0074] Step 9. Directly acquire the OSQ lock and spin on the mutex lock. Here, the current thread becomes the lock holder and can immediately enter the critical section to execute critical code without waiting.
[0075] Step 10. Wait for the previous thread to hold the lock and for the CPU to pass the lock. If the current thread is not the first thread in the queue, it will wait for the previous thread to hold the lock and pass it to itself. Then, jump to step 11.
[0076] Step 11. When the predecessor releases the lock, it writes to my osq_node. When the current lock holder releases the lock, it will actively access the current thread's osq_node and write the "lock passed" flag. Then, jump to step 12.
[0077] Step 12. My CPU learns that the lock has been acquired through cache synchronization. The current thread, while spinning and waiting, only observes the flag in its local osq_node to obtain the flag information; because the predecessor modified this value, the local CPU's cache line is invalidated and reloaded, thus discovering that the lock has been passed. Then, proceed to step 13.
[0078] Step 13. Spin on the mutex lock. Once the current thread finds that it has acquired the lock, it immediately enters the critical section to perform the critical task. Then, jump to step 14.
[0079] Step 14. Acquire the mutex lock and prepare to release the OSQ lock. After the current thread completes its task, it prepares to release the lock and pass it to the next waiting thread (if any). Then, jump to step 15.
[0080] Step 15. Does the current NUMA node have a successor node that records the chained successor node information (i.e., the next queuer) in its osq_node? The current thread reads this field to determine if there is a waiting node. If it exists, proceed to step 16; if it does not exist, proceed to step 17.
[0081] Step 16. If a successor node exists, a pseudo-random mechanism is used to determine whether to pass the lock within the current NUMA node or across NUMA nodes. For example, a pseudo-random algorithm can be used to calculate a probability parameter (INTRA_NODE_HANDOFF_PROB_ARG), and the result (yes or no) is determined based on whether the value of the probability parameter exceeds a preset value. If the determination is yes, proceed to step 20; if the determination is no, proceed to step 21.
[0082] Step 17. If there is no successor node in the local NUMA node queue, then search for the waiter in the remote NUMA node queue. If there is, proceed to step 18; otherwise, proceed to step 19.
[0083] Step 18. If there are waiting threads in the remote NUMA node queue, then pass the lock to the remote NUMA node thread.
[0084] Step 19. If there are no waiting threads in the remote NUMA node queue, exit directly.
[0085] Step 20. If the determination is yes, then pass the lock on this NUMA node.
[0086] Step 21. If the determination is negative, then pass the lock across NUMA nodes.
[0087] The above describes the node-aware optimistic spin queue lock processing method under the NUMA architecture of this application embodiment.
[0088] In step 2, the queue is divided into multiple parts (according to the number of NUMA nodes), which can effectively reduce cross-NUMA memory access caused by lock passing.
[0089] In step 3, since the number of queues increases to NUMA (the same as the number of NUMA nodes), the mutex and read-write lock structures increase in size by 4 * MAX_NUMNODES bytes. Therefore, a hash key is generated using a hash table based on the OSQ instance address in mutex / rw_semaphore. The tail in optimistic_spin_queue changes from the queue tail to a hash key, and the value is a globally static array of size 2^HASH_BITS_LEN. The array elements are the original queue tail array, and the number of array elements is the number of NUMA nodes. With HASH_BITS_LEN = 15, only a static 4MB space is added.
[0090] In step 16, the potential starvation problem was addressed by introducing a pseudo-random mechanism, which determines whether to switch NUMA nodes during lock delivery. Furthermore, the INTRA_NODE_HANDOFF_PROB_ARG parameter was provided to adjust the balance between fairness and performance.
[0091] The optimization results of unixbench file copy under arm64 and 4numa architectures are shown in Table 1 below.
[0092] Table 1
[0093]
[0094] The features of this application include:
[0095] 1) OSQ lock optimization method under NUMA architecture: The core design is based on the partitioning of queues by NUMA nodes, including queue creation, management and hash mapping mechanism.
[0096] 2) Dynamic decision-making algorithm for cross-node lock passing: pseudo-random mechanism and its parameterized implementation, ensuring that thread starvation is avoided while reducing cross-node access.
[0097] 3) Lightweight hash table and queue storage structure: A technical solution for efficiently managing multiple NUMA queues through hash tables, including hash key generation and static array design.
[0098] The beneficial effects achieved by adopting the above technical solutions in this application include, but are not limited to:
[0099] 1) Divide the traditional global OSQ lock queue into multiple sub-queues (i.e. multiple NUMA node queues) according to NUMA nodes, which can reduce cache invalidation and high latency issues caused by cross-node memory access.
[0100] 2) Dynamically manage queues using hash tables to avoid a surge in memory usage due to an increase in the number of queues (related to the number of NUMA nodes) (for example, only 4MB of static space is required).
[0101] 3) Solve the starvation problem of a queue by using a pseudo-random lock passing mechanism. When the lock is released, a pseudo-random algorithm is used to determine whether to pass the lock to the successor thread of the local NUMA node or to the thread of another NUMA node across nodes.
[0102] 4) Introduce the probability parameter INTRA_NODE_HANDOFF_PROB_ARG (node-internal lock propagation probability parameter) to dynamically adjust the probability of local and cross-node propagation, balancing fairness and performance.
[0103] refer to Figure 3 , Figure 3 This is a flowchart of an embodiment of the node-aware optimistic spin queue lock processing method according to this application. The node-aware optimistic spin queue lock processing method of this application is applied to a NUMA architecture system, where the system manages multiple optimistic spin queue locks, and each optimistic spin queue lock corresponds one-to-one with multiple NUMA nodes.
[0104] like Figure 3 As shown, the method of this application includes the following steps:
[0105] Step 301: The current thread determines whether the local NUMA node already has a corresponding NUMA node queue by looking up the hash table;
[0106] Step 302: If it already exists, acquire the optimistic spin queue lock through the NUMA node queue;
[0107] Step 303: Determine to release the optimistic spin queue lock;
[0108] Step 304: Calculate the probability parameter using a pseudo-random algorithm. Determine whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes based on whether the probability parameter exceeds a preset value.
[0109] In some optional implementations, step 301 includes: the current thread obtaining the identifier of the local NUMA node where the current CPU is located; obtaining the optimistic spin queue lock instance address based on the obtained local NUMA node identifier; generating a hash key based on the obtained optimistic spin queue lock instance address; and determining whether the local NUMA node already has a corresponding NUMA node queue by looking up the hash table.
[0110] In some optional implementations, step 302 includes: adding the local optimistic spin queue lock node to the NUMA node queue; waiting for the predecessor lock-holding CPU to pass the optimistic spin queue lock; and obtaining the optimistic spin queue lock through cache synchronization.
[0111] In some optional implementations, after step 301, the method further includes: if it does not exist, creating a NUMA node queue corresponding to the local NUMA node, adding the local optimistic spin queue lock node to the NUMA node queue, and directly acquiring the optimistic spin queue lock.
[0112] In some optional implementations, after step 303, the method further includes: determining whether the NUMA node queue has a successor optimistic spin queue lock node; if so, performing a step of calculating probability parameters using a pseudo-random algorithm.
[0113] In some optional implementations, after determining whether the NUMA node queue has a successor optimistic spin queue lock node, the method further includes: if it does not exist, checking whether there is a waiting thread in the remote NUMA node queue corresponding to other NUMA nodes; if it does exist, passing the optimistic spin queue lock to the waiting thread of the remote NUMA node queue.
[0114] In some optional implementations, after checking whether there are waiting threads in the remote NUMA node queues corresponding to other NUMA nodes, the method further includes: if not, exiting directly.
[0115] For a more detailed description of the method in this embodiment, please refer to the preceding text. Figure 2 The description.
[0116] refer to Figure 4 , Figure 4 This is a schematic diagram of a node-aware optimistic spin queue lock processing device according to an embodiment of this application. The device of this application is applied to a NUMA architecture system, which manages multiple optimistic spin queue locks, and the multiple optimistic spin queue locks correspond one-to-one with multiple NUMA nodes.
[0117] like Figure 4 As shown, the node-aware optimistic spin queue lock processing device 400 of this application may include:
[0118] The lookup module 401 is configured to enable the current thread to determine whether a local NUMA node already exists in the corresponding NUMA node queue by looking up a hash table.
[0119] Module 402 is configured to acquire an optimistic spin queue lock through the NUMA node queue if the search module is determined to exist.
[0120] Module 403 is configured to release the optimistic spin queue lock.
[0121] The calculation module 404 is configured to calculate the probability parameter using a pseudo-random algorithm, and determine whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes based on whether the probability parameter exceeds a preset value.
[0122] It should be noted that the implementation details and technical effects of each module in the device of this embodiment can be found in the descriptions of other embodiments in this application, and will not be repeated here. The implementation schemes of each module of this device are diverse, as long as the purpose of the module can be achieved, and the actual deployment is not limited to the specific implementation scheme.
[0123] refer to Figure 5 , Figure 5 This is a schematic diagram of the structure of a computer device for implementing a server according to an embodiment of this application. Figure 5 As shown, the computer device 500 of this application may include:
[0124] One or more processors 501;
[0125] Memory 502, on which one or more programs 503 are stored;
[0126] Components such as processor 501 and memory 502 can be coupled together via bus system 504; bus system 504 is used to realize the connection and communication between these components.
[0127] When one or more programs 503 are executed by one or more processors 501, the one or more processors 501 implement the node-aware optimistic spin queue lock processing method disclosed in the above method embodiments.
[0128] The bus system 504 may include a data bus, a power bus, a control bus, and a status signal bus. The memory 502 may be volatile or non-volatile, or both. The processor 501 may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0129] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by one or more processors, implements the node-aware optimistic spin queue lock processing method disclosed in the above method embodiments.
[0130] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0131] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0132] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0133] It should be understood that the terms "system" and "network" are often used interchangeably in this application. The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Furthermore, the character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship.
[0134] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A node-aware optimistic spin queue lock processing method, applied to a NUMA architecture system, characterized in that, The system manages multiple optimistic spin queue locks, each corresponding one-to-one with a NUMA node. The method includes: The current thread determines whether the local NUMA node already has a corresponding NUMA node queue by looking up the hash table; If it already exists, acquire the optimistic spin queue lock through the NUMA node queue; Determine to release the optimistic spin queue lock; The probability parameter is calculated using a pseudo-random algorithm. Based on whether the probability parameter exceeds a preset value, it is determined whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes.
2. The method according to claim 1, characterized in that, The current thread determines whether a corresponding NUMA node queue already exists on the local NUMA node by looking up a hash table, including: The current thread obtains the identifier of the local NUMA node where the current CPU resides; Based on the identifier of the local NUMA node, obtain the address of the optimistic spin queue lock instance; A hash key is generated based on the obtained optimistic spin queue lock instance address. By looking up the hash table, it is determined whether the corresponding NUMA node queue already exists on the local NUMA node.
3. The method according to claim 1, characterized in that, The step of acquiring the optimistic spin queue lock through the NUMA node queue includes: Add the local optimistic spin queue lock node to the NUMA node queue; Waiting for the predecessor holding the lock CPU to pass the optimistic spin queue lock; The optimistic spin queue lock is determined by cache synchronization.
4. The method according to claim 1, characterized in that, After the current thread determines whether a corresponding NUMA node queue already exists on the local NUMA node by looking up a hash table, the method further includes: If it does not exist, create a NUMA node queue corresponding to the local NUMA node, add the local optimistic spin queue lock node to the NUMA node queue, and directly acquire the optimistic spin queue lock.
5. The method according to claim 1, characterized in that, After determining to release the optimistic spin queue lock, the method further includes: Determine whether the NUMA node queue has a successor optimistic spin queue lock node; If it exists, perform the step of calculating the probability parameters using a pseudo-random algorithm.
6. The method according to claim 5, characterized in that, After determining whether the NUMA node queue has a successor optimistic spin queue lock node, the method further includes: If not found, check if there are waiting threads in the queues of other remote NUMA nodes. If it exists, pass the optimistic spin queue lock to the waiting thread of the remote NUMA node queue.
7. The method according to claim 6, characterized in that, After checking whether there are waiting threads in the remote NUMA node queues corresponding to other NUMA nodes, the method further includes: If it does not exist, exit directly.
8. A node-aware optimistic spin queue lock processing method and apparatus, applied to a NUMA architecture system, characterized in that, The system manages multiple optimistic spin queue locks, each corresponding one-to-one with a multiple NUMA node. The device includes: The lookup module is configured to enable the current thread to determine whether a local NUMA node already exists in the corresponding NUMA node queue by looking up a hash table. The acquisition module is configured to acquire an optimistic spin queue lock through the NUMA node queue if the search module determines that the node already exists. The module is configured to release the optimistic spin queue lock definitively. The calculation module is configured to calculate probability parameters using a pseudo-random algorithm. Based on whether the probability parameters exceed a preset value, it determines whether to pass the optimistic spin queue lock on the local NUMA node or across NUMA nodes.
9. A computer device, characterized in that, include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by one or more processors, implements the method as described in any one of claims 1-7.