A critical section execution method and device in a NUMA system

Abstract

The embodiment of the present application provides a critical section execution method and device in a NUMA system. In the NUMA system, even if the number of threads competing for locks concurrently is large, the performance of the lock will not be affected. The critical section execution method in the NUMA system provided by the present application includes: a first thread running on a node of the NUMA system determines a target queue corresponding to the critical section, the NUMA system includes multiple nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread executes the critical section based on obtaining a first data packet from the target queue.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a critical section execution method and device in a non-uniform memory access (NUMA) system. Background Art

[0002] Non-uniform memory access (NUMA) is a multi-processor computer memory architecture. The memory access time in a NUMA-based computer system depends on the location of the memory relative to the processor. A computer system using the NUMA architecture usually includes multiple NUMA nodes, each of which contains several processors and physical memory (managed by independent memory controllers). The processor accesses its own local memory faster than non-local memory (memory located in another node, or memory shared between processors).

[0003] When multiple threads in the system need to execute critical sections on the same shared resource, in order to prevent conflicts, each thread needs to compete for the spin lock corresponding to the shared resource before executing the critical section. Spin lock is a lock introduced to prevent multi-processor concurrency. At any time, a spin lock can be held by at most one thread. If a thread attempts to request a spin lock that is already held by another thread, the task can loop and try to obtain the spin lock, waiting for the spin lock to be available again. If the spin lock is not held by any other thread, the thread requesting the spin lock can directly obtain the spin lock to execute the critical section on the shared resource protected by the spin lock.

[0004] Since the spin lock itself is a variable in the shared memory, in a computer system with NUMA architecture, the shared memory may be distributed in the memory of any node. Therefore, when each thread competes for the shared memory, the threads distributed in multiple nodes need to access the variables in the shared memory. For threads on nodes far away from the node to which the variables in the shared memory belong, accessing the variables in the shared memory has a very high access latency. As the number of threads competing for the spin lock increases, the performance of the spin lock will drop significantly. Summary of the invention

[0005] The present application provides a critical section execution method and device in a NUMA system, which are used to reduce the latency overhead caused by concurrent lock contention among multiple threads in the NUMA system and improve lock performance.

[0006] In a first aspect, an embodiment of the present application provides a critical section execution method in a non-uniform memory access NUMA system, comprising: a first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system comprising multiple nodes, wherein each node has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread executes the critical section based on obtaining a first data packet from the target queue.

[0007] In the above manner, the critical section is bound to a specific hardware queue in the NUMA node, and the application and release of the spin lock of the critical section are converted into the packet adding and packet fetching operations of the hardware queue, and whether the critical section can be executed is determined based on whether the data packet can be obtained from the hardware queue bound to the critical section. Since the time consumed by the hardware queue in the NUMA node to fetch packets is shorter than the time to read the lock variable from the memory, and since the acquired data does not need to be written to the cacheline, the system will not have a large number of cache misses caused by the lock variable being written to the cacheline in the prior art. Even if the number of threads competing for the lock concurrently in the NUMA system is large, the impact on the performance of the lock is relatively small.

[0008] In a possible design of the first aspect, after the first thread executes the critical section, the first thread adds the second data packet to the target queue. In this way, the release of the spin lock of the critical section is converted into a packet adding operation of the hardware queue, and other threads can subsequently obtain the data packet from the target queue and then execute the critical section without accessing the lock variable in the memory, thereby greatly reducing the latency.

[0009] In a possible design of the first aspect, the critical section uniquely corresponds to a hardware queue in the hardware queues of the multiple nodes. That is, a critical section can be bound to a specific hardware queue in a NUMA node, so that each hardware queue represents a lock that protects the critical section. The thread obtains a packet from the hardware queue bound to the critical section. If the packet is obtained, it means that the lock can be preempted and the critical section can be executed. After the thread completes the critical section execution, it adds a packet to the hardware queue bound to the critical section, which means that the thread has released the lock of the critical section, and other threads waiting to obtain the lock of the critical section can obtain the lock (get the packet) and then execute the critical section.

[0010] In a possible design of the first aspect, the low latency characteristic of inserting and acquiring data packets in the hardware queue is utilized to put the state value of the spin lock for the critical section into the hardware queue, thereby avoiding the overhead of accessing the spin lock state value from the memory, especially the high latency overhead of accessing the lock state value in the remote memory.

[0011] In a possible design of the first aspect, the first thread obtains an identification ID of a target queue corresponding to the critical section.

[0012] In a possible design of the first aspect, the method also includes: the first thread sends the ID of the target queue to the hardware accelerator; the first thread receives the first data packet returned by the hardware accelerator according to the ID of the target queue, wherein the first data packet is a data packet in the target queue.

[0013] In a possible design of the first aspect, the first thread obtains the identification ID of the target queue corresponding to the critical section, including: the first thread obtains the identification ID of the target queue from lock information corresponding to the critical section.

[0014] In a possible design of the first aspect, the first thread adds the second data packet to the target queue, including: the first thread sends the ID of the target queue and the second data packet to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

[0015] In a possible design of the first aspect, the target queue is a first-in-first-out queue. In this way, it can be ensured that the thread that first applies to obtain the data packet in the target queue can obtain it first, so that the thread that later applies to obtain the data packet in the target queue will not execute the critical section first, thereby ensuring the fairness of the execution of the critical section by each thread.

[0016] In a possible design of the first aspect, the method further includes: the first thread, based on not obtaining the first data packet from the target queue, waits for a preset time and then repeats the step of obtaining the data packet from the target queue until the first data packet is obtained. In this way, the action of the thread cyclically obtaining the spin lock is converted into the action of obtaining the packet from the target queue.

[0017] In a second aspect, the present application provides a critical section execution device in a NUMA system, the device comprising: a processor and a memory, the memory being used to execute a program stored in the storage area to execute the method in the first aspect or any possible design of the first aspect.

[0018] In a third aspect, the present application provides a critical section execution device in a NUMA system, the device comprising: a determination module, used to determine a target queue corresponding to the critical section, the NUMA system comprising multiple nodes, wherein each node has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; an execution module, used to execute the critical section based on obtaining a first data packet from the target queue.

[0019] In a possible design of the second aspect, the device also includes: a transceiver module, used to add a second data packet to the target queue after executing the critical section.

[0020] In a possible design of the second aspect, the critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes.

[0021] In a possible design of the second aspect, the determination module is specifically used to obtain an identification ID of a target queue corresponding to the critical section.

[0022] In a possible design of the second aspect, the transceiver module is specifically used to: send the ID of the target queue to the hardware accelerator; receive the first data packet returned by the hardware accelerator according to the ID of the target queue, wherein the first data packet is a data packet in the target queue.

[0023] In a possible design of the second aspect, the determination module is specifically used to obtain an identification ID of the target queue from the lock information corresponding to the critical section.

[0024] In a possible design of the second aspect, the transceiver module is specifically used to send the ID of the target queue and the second data packet to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

[0025] In a possible design of the second aspect, the target queue is a first-in-first-out queue.

[0026] In a possible design of the second aspect, it is characterized in that the transceiver module is also used to: based on not obtaining the first data packet from the target queue, wait for a preset time and then repeat the step of obtaining the data packet from the target queue until the first data packet is obtained.

[0027] In an embodiment of the present application, a first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system includes multiple nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread executes the critical section based on obtaining a first data packet from the target queue. In the above manner, the physical queue and the critical section are bound, and whether the critical section can be executed is determined based on whether the data packet can be obtained from the physical queue. Since the time consumed by the physical queue to obtain the packet is shorter than the time to read the lock variable from the memory, and since the obtained data does not need to be written to the cache, the system will not have a large number of cache misses caused by the lock variable being written to the cache in the prior art. In a NUMA system, even if the number of threads competing for the lock concurrently is large, it will not affect the performance of the lock. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A schematic diagram of the architecture of a NUMA system provided in an embodiment of the present application;

[0029] Figure 2 A schematic diagram of the connection between two nodes in a NUMA architecture;

[0030] Figure 3 A schematic diagram of a critical section execution method in a NUMA system provided in an embodiment of the present application;

[0031] Figure 4a to Figure 4h A schematic diagram of a critical section execution according to an embodiment of the present application;

[0032] Figure 5 A schematic diagram of a critical section execution process of an embodiment of the present application;

[0033] Figure 6 A schematic diagram of the structure of a critical section execution device in a NUMA system provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of the structure of a NUMA node provided in an embodiment of the present application;

[0035] Figure 8 A schematic diagram of the structure of a NUMA system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The following describes the embodiments of the present application in conjunction with the accompanying drawings. Obviously, the described embodiments are only embodiments of a part of the present application, rather than all embodiments. It is known to those skilled in the art that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0037] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described here can be implemented in an order other than that illustrated or described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or modules is not necessarily limited to those steps or modules clearly listed, but may include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices. The naming or numbering of steps in this application does not mean that the steps in the method flow must be executed in the time or logical sequence indicated by the naming or numbering. The process steps that have been named or numbered can change the execution order according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved.

[0038] The following first introduces the application scenario of the present application. In the architecture of the NUMA system 100, it can be a multi-socket system 100. Figure 1 , Figure 1 A schematic diagram of the architecture of a NUMA system 100 provided in an embodiment of the present application is shown in FIG. Figure 1As shown in FIG. 1 , the NUMA system 100 includes a socket 101a and a socket 101b. The socket 101a and the socket 101b may be collectively referred to as a socket 101 herein, and may be used to install a central processing unit (CPU). The sockets 101 may be communicatively coupled to each other via an interconnect 104. Exemplarily, each socket 101 may be connected to each of the other sockets 101 via a point-to-point quick path interconnect (QPI) link. It should be noted that QPI is an interconnect architecture, and the interconnection between the various sockets in the embodiment of the present application may also be implemented by other interconnect architectures, such as other point-to-point architectures, ring architectures, and bus architectures, which are not limited here. The number of sockets depicted in the NUMA system 100 is only an example, and those skilled in the art will understand that there may be different numbers of sockets. For example, the NUMA system 100 may include, for example, six, four, or fewer sockets, or the NUMA system 100 may include, for example, sixteen, thirty-two, or more sockets.

[0039] The slot 101 may include multiple nodes, each of which has its own CPU and memory, and the nodes are connected and communicated with each other through the interconnection 104. Figure 1 As shown in FIG. 1 , slot 101a includes node 102a and node 102b, slot 101b includes node 103a and node 103b, and each node includes a memory and six CPUs. It should be noted that the number of nodes and CPUs depicted in NUMA system 100 is only an example, and those skilled in the art will understand that each slot may include other numbers of nodes, and each node may include other numbers of CPUs.

[0040] For the CPU in each node, the memory it accesses has two distances: one is the memory in the node, that is, the near-end memory; the other is the memory in other nodes, that is, the far-end memory. Figure 2 , Figure 2 It is a schematic diagram of the connection between two nodes in a NUMA architecture, such as Figure 2 As shown in the figure, when the CPU on node 201 accesses the memory on node 202 (remote access), it needs to be transmitted through the interconnection 104, while the CPU on node 201 accesses the memory of node 201 itself (near-end access) only through the memory channel. The time required for remote access is obviously greater than the time required for near-end access.

[0041] Shared resources are memory resources that all threads need to access. They are stored in the shared memory of a certain node, and the code segment that executes shared resources can be called a critical section. When different threads in the NUMA system 100 access shared resources or critical resources (execute the critical section of the shared resource), it is necessary to ensure that only one thread can operate on the shared resource at the same time, that is, at the same time, the same critical section can only be executed by one thread. Specifically, locks can be used to protect critical sections. Multiple threads need to apply for locks before executing critical sections on the same shared resource. Only threads holding locks can execute critical sections, and the locks are released after the critical sections are executed.

[0042] For example, taking the shared resource as variable a, thread 1 running in NUMA system 100 needs to execute critical section {a=a+1}, and thread 2 running in NUMA system 100 needs to execute critical section {a=a+2}. Since critical section {a=a+1} and critical section {a=a+2} are both operations performed on the same shared resource, it is necessary to protect critical section {a=a+2} and critical section {a=a+2} through a lock (lock 1). When thread 1 is about to execute critical section {a=a+1}, it needs to compete for lock 1, and based on the competition for lock 1, execute critical section {a=a+1}, and release lock 1 after executing critical section {a=a+1}. When thread 2 is about to execute the critical section {a=a+2}, it needs to compete for lock 1. If lock 1 is held by other threads (such as thread 1) at this time, thread 2 needs to wait until it obtains (lock 1), executes the critical section {a=a+2}, and releases lock 1 after executing the critical section {a=a+2}.

[0043] In another scenario, when different threads in the NUMA system 100 access different shared resources (execute critical sections of different shared resources), it is also necessary to ensure that only one thread can operate on the shared resources at the same time. At this time, a lock is also needed to protect the critical section. Multiple threads need to apply for a lock before executing the critical section protected by the lock. Only the thread holding the lock can execute the critical section, and the lock is released after the critical section is executed.

[0044] Exemplarily, thread 1 running in NUMA system 100 needs to execute critical section {c=c+1}, and thread 2 running in NUMA system 100 needs to execute critical section {a=b; b=c; c=d}. Since critical section {c=c+1} and critical section {a=b; b=c; c=d} require one of the critical sections to be executed before the other critical section can be executed, a lock (lock 2) is needed to protect critical section {c=c+1} and critical section {a=b; b=c; c=d}. When thread 1 is about to execute critical section {c=c+1}, it needs to compete for lock 2, and based on the competition for lock 2, execute critical section {c=c+1}, and release lock 2 after executing critical section {c=c+1}. When thread 2 is about to execute the critical section {a=b; b=c; c=d}, it needs to compete for lock 2. If lock 2 is held by other threads (such as thread 1) at this time, thread 2 needs to wait until it obtains (lock 2), executes the critical section {a=b; b=c; c=d}, and releases lock 2 after executing the critical section {a=b; b=c; c=d}.

[0045] It should be noted that the above solution that each thread needs to determine whether to execute criticality based on the result of lock contention is only an illustration and does not constitute a limitation of the present application.

[0046] Taking the spinlock as an example, at any time, a spinlock can be held by at most one thread. If a thread attempts to request a spinlock that is already held by another thread, the thread will loop and try to acquire the spinlock, waiting for the spinlock to be available again. If the spinlock is not held by any other thread, the thread requesting the spinlock can directly obtain the spinlock to execute the critical section protected by the spinlock.

[0047] The spin variable of the spin lock is stored in the shared memory, which can be located in the memory of any node in the server. Figure 2 For example, the shared memory can be located in the memory of node 202. If a thread of a CPU located in node 201 needs to execute a critical section on a shared resource in the shared memory located in node 202, the thread needs to obtain the spin variable of the spin lock corresponding to the critical section from the shared memory of 202.

[0048] If the acquired spin variable is 0, it means that the spin lock is not held by any other thread, then the spin lock can be acquired and the spin variable is set to 1, indicating that the spin lock is already held by a thread. After that, the thread holding the spin lock executes the critical section and sets the spin variable to 0 after executing the critical section, indicating that the spin lock is not held by any thread.

[0049] If the acquired spin variable is 1, it means that the spin lock is already held by other threads. The thread will loop to acquire the spin variable of the spin lock until the acquired spin variable is 0, which is equivalent to confirming that the spin lock is not held by any other thread. The thread can acquire the spin lock and set the spin variable to 1, indicating that the spin lock is already held by a thread. After that, the thread holding the spin lock executes the critical section and sets the spin variable to 0 after executing the critical section, indicating that the spin lock is not held by any thread.

[0050] In a server based on the NUMA architecture, threads distributed in various nodes need to access the spin variable corresponding to the spin lock when executing the critical section protected by the spin lock. For threads on the NUMA node farthest from the node storing the spin variable, accessing this spin variable has a very high access latency.

[0051] At the same time, threads accessing the spin variable need to first load the spin variable from the shared memory to the corresponding cache line cacheline. If the spin variable obtained by the thread is 0, it means that the spin lock is not held by any other thread, then the spin variable is set to 1. At this time, in the cacheline of the node to which the threads of other critical sections to be protected by the spin lock belong, the stored spin variables are invalid (due to changes in the spin variables), resulting in a large number of cache misses in the system.

[0052] In a server based on the NUMA architecture, there are a large number of nodes, each node is deployed with a large number of CPUs, and there may be a large number of threads in the server that need to execute a critical section protected by a lock. Since there is a certain delay when each thread obtains a spin lock, in the scenario where multiple threads concurrently execute a critical section protected by a spin lock, the performance of the spin lock will be reduced, and as the number of concurrency increases, the degree of performance degradation will be greater (the higher the number of concurrency).

[0053] In order to solve the above problems, the present application provides a critical section execution method in a NUMA system, referring to Figure 3 , Figure 3 A schematic diagram of a critical section execution method in a NUMA system provided in an embodiment of the present application is shown as follows: Figure 3 As shown, the critical section execution method in the NUMA system provided by the present application specifically includes:

[0054] 301. A first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system comprising a plurality of nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the plurality of nodes.

[0055] In an embodiment of the present application, a NUMA system may include a plurality of interconnected nodes, each node having at least one hardware queue. Exemplarily, the hardware queue of each node may be located in a dedicated static random access memory (SRAM). The access speed of the hardware queue is similar to the access speed of the cache. Each queue may be configured with the number and width of elements included. At the same time, the CPU of each node may include a hardware accelerator that provides services for the hardware queue. How the hardware accelerator provides services for the hardware queue will be described in subsequent embodiments and will not be repeated here. It should be noted that the above-mentioned static random access memory SRAM is a type of random access memory. As long as the static random access memory SRAM remains powered on, the data stored therein can be kept constant. In one embodiment, the hardware queue may be a POE (Packet Order Enforcer) hardware lock-free queue, referred to as a POE queue. The POE queue is located in a node-specific SRAM, and the atomicity of adding and taking packets from the queue is guaranteed by the POE hardware.

[0056] In an embodiment of the present application, when the NUMA system starts the database and initializes the database, it can first bind the lock to the hardware queue. Specifically, for critical sections that need to be executed atomically with each other, they can be protected by locks. In this embodiment, each lock (critical section that needs to be executed atomically with each other) can be bound to a hardware queue in multiple nodes, which is equivalent to establishing a binding relationship between the lock (critical section that needs to be executed atomically with each other) and the hardware queue.

[0057] In the embodiment of the present application, each lock corresponds to a critical section that needs to be executed atomically. If a thread runs to a critical section, the hardware queue corresponding to the critical section can be determined through the binding relationship between the critical section (lock) and the hardware queue.

[0058] It should be noted that in order to ensure that the critical sections that need to be executed atomically correspond to the same lock, and the critical sections that need to be executed atomically correspond to the only one lock, the critical sections that need to be executed atomically correspond to the same and only one hardware queue in the NUMA system.

[0059] In an embodiment of the present application, each node has at least one hardware queue, and each hardware queue may correspond to an ID of a target queue, wherein the ID of the target queue may include the node ID of the node where the target queue is located and the queue ID of the node where the target queue is located. Specifically, the node ID and queue ID of the node where the bound hardware queue is located may be recorded in the lock information of each lock. If a thread needs to execute a critical section, the lock information corresponding to the critical section may be queried, and the node ID and queue ID corresponding to the critical section may be obtained. In the above manner, the first thread realizes the determination of the target queue corresponding to the critical section.

[0060] Next, a schematic diagram of the process of binding a lock to a hardware queue is described. Exemplarily, the server includes n nodes (node ​​1 to node n), each node has m hardware queues (queue 1 to queue m), then the total number of hardware queues of the server = n*m, the server includes a total of x shared resources, corresponding to x locks (lock 1 to lock x), lock 1 is bound to queue 1 in node 1, that is, (node ​​1 and queue 1) is recorded in the lock information of lock 1, that is, lock 1 is bound to queue 1 in node 1, and by analogy, the remaining x-1 locks are bound to the remaining queues.

[0061] For example, taking the shared resource as variable a, thread 1 running in the NUMA system 100 needs to execute the critical section {a=a+1}, and thread 2 running in the NUMA system 100 needs to execute the critical section {a=a+2}, then the critical section {a=a+1} and the critical section {a=a+2} are critical sections that need to be executed atomically with each other, and the critical section {a=a+1} and the critical section {a=a+2} correspond to one target queue.

[0062] It should be noted that the critical sections that need to be executed atomically may not correspond to the same shared resource. For example, refer to the example in which thread 1 running in the above-mentioned NUMA system 100 needs to execute the critical section {c=c+1}, and thread 2 running in the NUMA system 100 needs to execute the critical section {a=b; b=c; c=d}. At this time, the critical section {c=c+1} and the critical section {a=b; b=c; c=d} do not correspond to the same shared resource, but they still need to be executed atomically. Therefore, the above-mentioned critical section {c=c+1} and the critical section {a=b; b=c; c=d} need to correspond to the same target queue.

[0063] In an embodiment of the present application, a node in a NUMA system runs a first thread, and the first thread includes a critical section. When the first thread is about to execute the critical section, the target queue corresponding to the critical section can be determined (for example, the ID of the corresponding target queue can be obtained).

[0064] Optionally, in one implementation, when the first thread is about to execute the critical section, the lock information corresponding to the critical section can be obtained, and the lock information includes the ID of the target queue corresponding to the critical section. The first thread can implement the step of determining the target queue corresponding to the critical section by obtaining the ID of the target queue corresponding to the critical section. It should be noted that the above-mentioned acquisition of the lock information corresponding to the critical section can be implemented by setting a task pointer for accessing the lock information in the critical section. Specifically, before the first thread executes the critical section, it can access the corresponding location of the memory based on the task pointer for accessing the lock information and obtain the lock information.

[0065] Exemplarily, a node in a NUMA system runs a first thread, which includes a critical section {a=a+1}. The critical section {a=a+1} corresponds to lock information, and the lock information stores the ID of the hardware queue {node 2, queue 5}. When the first thread is about to execute the critical section {a=a+1}, it needs to obtain the corresponding lock information and obtain the ID of the hardware queue {node 2, queue 5} from the corresponding lock information.

[0066] 302. The first thread executes the critical section based on obtaining a first data packet from the target queue.

[0067] In the embodiment of the present application, after the first thread determines the target queue corresponding to the critical section, the first thread can obtain the first data packet in the target queue.

[0068] Optionally, after the first thread obtains the ID of the target queue corresponding to the critical section, the first thread can send the ID of the target queue to the hardware accelerator, and enable the first thread to receive a first data packet returned by the hardware accelerator according to the ID of the target queue or return a result indicating NULL, wherein the first data packet is a data packet in the target queue.

[0069] In an embodiment of the present application, the hardware accelerator can provide two interfaces: a first interface and a second interface, wherein the first interface is used to receive the ID of the target queue, and the second interface is used to output the data packets in the target queue when the target queue is not empty, or, when the target queue is empty, output a result indicating NULL.

[0070] It should be noted that the description of the above interface is only an illustration. In actual applications, interfaces with other functions may be deployed in the hardware accelerator, or the functions of the above two interfaces may be integrated into one interface for implementation, which is not limited here.

[0071] In the embodiment of the present application, each node in the server may be provided with a corresponding hardware accelerator, and each hardware accelerator may maintain a hardware queue in a local node. The first thread may obtain the node ID of the node to which the target queue belongs, and route to the hardware accelerator in the corresponding node through the obtained node ID, and send the ID of the target queue to the first interface of the hardware accelerator.

[0072] In one embodiment, the ID of the target queue is the aforementioned queue ID.

[0073] Specifically, if the target queue corresponding to the critical region is a queue local to the target node, the queue ID of the target queue can be directly sent to the local hardware accelerator. If the target queue corresponding to the critical resource is not a queue local to the target node, it needs to be routed to the hardware accelerator of the corresponding node, and the queue ID of the target queue is sent to the routed hardware accelerator.

[0074] Correspondingly, after the hardware accelerator receives the queue ID of the target queue sent by the first thread, if the target queue is not empty, the first data packet in the target queue can be sent to the first thread through the second interface, so that the first thread obtains the first data packet in the target queue.

[0075] If the target queue is empty, the hardware accelerator may send a result representing NULL to the first thread.

[0076] In the embodiment of the present application, the first thread can determine whether the critical section task can be executed according to whether the first data packet of the target queue is obtained.

[0077] It should be noted that in the embodiment of the present application, when initializing the database, the hardware accelerator can clear the hardware queue and put a non-empty variable in each hardware queue, indicating that the lock corresponding to the hardware queue is not held by any thread.

[0078] In the embodiment of the present application, after the first thread receives the first data packet returned by the hardware accelerator according to the ID of the target queue, it can be determined that the lock corresponding to the critical section is not held by other threads, and then the first thread can execute the critical section.

[0079] Optionally, if the first thread does not receive the first data packet returned by the hardware accelerator according to the ID of the target queue, that is, the first thread receives a result indicating NULL returned by the hardware accelerator, the first thread can determine that the lock corresponding to the critical section is held by other threads, and wait for a preset time and then repeat the step of obtaining the data packet from the target queue until the first data packet is obtained. Specifically, the first thread can wait for a preset time and then send the ID of the target queue to the hardware accelerator until the first data packet returned by the hardware accelerator according to the ID of the target queue is received, then the first thread can determine that the lock corresponding to the critical section is not held by other threads, and then the first thread can execute the critical section.

[0080] In an embodiment of the present application, when the first thread executes a critical section, if other threads also run to a critical section that needs to be executed atomically with the critical section executed by the first thread, they can try to obtain a data packet from the corresponding hardware queue. Since the target queue does not include any data after the hardware accelerator sends the first data packet to the first thread, the other threads cannot obtain the first data packet from the target queue, but receive a result indicating NULL returned by the hardware accelerator, and then it can be determined that the lock is being held by other threads.

[0081] In an embodiment of the present application, after the first thread executes the critical section, the first thread can send the ID of the target queue and the second data packet to the hardware accelerator to instruct the hardware accelerator to write the second data packet into the target queue according to the ID of the target queue, which is equivalent to the second thread releasing the lock. At this time, data is stored in the target queue, indicating that the lock corresponding to the target queue is not held by any thread, and can then be acquired by other threads that want to execute the critical section protected by the lock corresponding to the target queue.

[0082] Optionally, in one embodiment, the target queue is a first-in-first-out queue.

[0083] In an embodiment of the present application, the target queue is a first-in-first-out queue, which can ensure that the thread that first applies to obtain the data packet in the target queue can obtain it first, so that there will be no situation where the thread that later applies to obtain the data packet in the target queue executes the critical section first, thereby ensuring the fairness of the execution of the critical section by each thread.

[0084] In one scenario, the shared resource corresponding to the critical section is a write ahead log buffer (WAL) cache.

[0085] In an embodiment of the present application, a business thread of a database needs to write the log into the WAL cache and store it on disk before submission. The WAL cache is a kind of shared resource and can be protected by the method provided in an embodiment of the present application.

[0086] In an embodiment of the present application, a first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system includes multiple nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread executes the critical section based on obtaining a first data packet from the target queue. In the above manner, the physical queue and the critical section are bound, and whether the critical section can be executed is determined based on whether the data packet can be obtained from the physical queue. Since the time consumed by the physical queue to obtain the packet is shorter than the time to read the lock variable from the memory, and since the obtained data does not need to be written to the cacheline, the system will not have a large number of cache misses caused by the lock variable being written to the cacheline in the prior art. In a NUMA system, even if the number of threads competing for the lock concurrently is large, it will not affect the performance of the lock.

[0087] Reference Figure 4a to Figure 4h , Figure 4a to Figure 4h Schematic diagram of a critical section execution in an embodiment of the present application. In the embodiment of the present application, thread 1 and thread 2 include critical sections that need to be protected by the same lock, such as Figure 4a As shown in the figure, thread 1 is a thread running on node 1, thread 2 is a thread running on node 2, node 1 has physical queues 1 to physical queues N, node 2 has physical queues 1 to physical queues N, and the physical queue corresponding to the above-mentioned critical sections included in thread 1 and thread 2 is physical queue 1 in node 1.

[0088] like Figure 4b As shown in , when thread 1 is about to execute the critical section, it needs to obtain the data packet in physical queue 1 in node 1. Specifically, thread 1 can obtain the ID of the corresponding physical queue (node ​​1, physical queue 1) from the lock information corresponding to the critical section to be executed, thread 1 can be routed to the hardware accelerator of node 1 based on node 1, and send the identifier of the physical queue (physical queue 1) to the hardware accelerator, the hardware accelerator can obtain the data packet from physical queue 1 based on the identifier of the physical queue (physical queue 1) sent by thread 1, and send the first data packet in physical queue 1 to thread 1.

[0089] like Figure 4c As shown in FIG. 1 , thread 1 obtains the first data packet in physical queue 1 and executes the critical section. At this time, there is no data packet in physical queue 1.

[0090] like Figure 4dAs shown in , at this time, when thread 2 is about to execute the critical section, it needs to obtain the data packet in the physical queue 1 in node 1. Specifically, thread 2 can obtain the ID of the corresponding physical queue (node ​​1, physical queue 1) from the lock information corresponding to the critical section to be executed. Thread 2 can be routed to the hardware accelerator of node 1 based on node 1, and send the identifier of the physical queue (physical queue 1) to the hardware accelerator. The hardware accelerator can obtain the data packet from the physical queue 1 based on the identifier of the physical queue (physical queue 1) sent by thread 2. However, there is no data packet in the physical queue 1 at this time. The hardware accelerator can return information indicating that the target queue is empty (for example, it can be a result indicating empty NULL). After receiving the information indicating that the target queue is empty, thread 2 can send the identifier of the physical queue (physical queue 1) to the hardware accelerator at preset intervals.

[0091] like Figure 4e As shown in FIG. 1 , after executing the critical section, thread 1 adds the second data packet to physical queue 1 . At this time, the second data packet is stored in physical queue 1 .

[0092] like Figure 4f As shown in the figure, after thread 2 sends the identifier of the physical queue (physical queue 1) to the hardware accelerator at a certain time, the hardware accelerator can obtain the second data packet from physical queue 2 based on the identifier of the physical queue (physical queue 1) sent by thread 2, and send the second data packet in physical queue 1 to thread 1.

[0093] like Figure 4g As shown in FIG. 1 , thread 2 obtains the second data packet in physical queue 1 and executes the critical section. At this time, there is no data packet in physical queue 1.

[0094] like Figure 4h As shown in FIG. 1 , after executing the critical section, thread 2 adds the third data packet to physical queue 1 . At this time, the third data packet is stored in physical queue 1 .

[0095] Reference Figure 5 , Figure 5 This is a schematic diagram of a critical section execution process of an embodiment of the present application, such as Figure 5 As shown in the figure, T1 represents the first thread, T2 represents the second thread, T1 includes critical section 1, T2 includes critical section 2, T1 and T2 are threads that execute tasks in parallel, from left to right is the execution sequence, and critical section 1 and critical section 2 are critical sections that need to be executed atomically with each other.

[0096] At time A1, T1 is about to execute critical section 1. At this time, T1 obtains the first data packet from the target queue in the time period A1-A2, executes the critical section in the time period A2-A3, and sends the second data packet to the target queue at time A4.

[0097] At time B1, T2 is about to execute critical section 2. T2 cannot obtain a data packet from the target queue during the time period B1-A4. During the time period A4-B2, T2 obtains the second data packet from the target queue and executes the critical section during the time period B2-B3. At time B4, T2 sends the third data packet to the target queue.

[0098] In the embodiment of the present application, the physical queue and the critical section are bound, and whether the critical section can be executed is determined based on whether a data packet can be obtained from the physical queue. Since the time consumed by the physical queue to obtain a packet is shorter than the time to read the lock variable from the memory, and since the obtained data does not need to be written into the cacheline, the system will not have a large number of cache misses caused by the lock variable being written into the cacheline in the prior art. In a NUMA system, even if the number of threads competing for the lock concurrently is large, it will not affect the performance of the lock.

[0099] In an embodiment of the present application, a first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system includes multiple nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread executes the critical section based on obtaining a first data packet from the target queue. In the above manner, the physical queue and the critical section are bound, and whether the critical section can be executed is determined based on whether the data packet can be obtained from the physical queue. Since the time consumed by the physical queue to obtain the packet is shorter than the time to read the lock variable from the memory, and since the obtained data does not need to be written to the cacheline, the system will not have a large number of cache misses caused by the lock variable being written to the cacheline in the prior art. In a NUMA system, even if the number of threads competing for the lock concurrently is large, it will not affect the performance of the lock.

[0100] The above describes the critical section execution method in the NUMA system in the embodiment of the present application. The following describes the critical section execution device in the NUMA system in the embodiment of the present application. Figure 6 , Figure 6 A schematic diagram of the structure of a critical section execution device in a NUMA system provided in an embodiment of the present application is shown in FIG. Figure 6 As shown in FIG. 1 , a critical section execution device in a NUMA system provided by an embodiment of the present application includes:

[0101] A determination module 601 is used to determine a target queue corresponding to a critical section, the NUMA system includes a plurality of nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the plurality of nodes;

[0102] The execution module 602 is used to execute the critical section based on obtaining the first data packet from the target queue.

[0103] Optionally, in one embodiment, the device further comprises:

[0104] The transceiver module 603 is used to add the second data packet to the target queue after executing the critical section.

[0105] Optionally, in one embodiment, the critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes.

[0106] Optionally, in an embodiment, the determining module 601 is specifically configured to:

[0107] Obtain the identification ID of the target queue corresponding to the critical section.

[0108] Optionally, in an embodiment, the transceiver module 603 is specifically used to:

[0109] Sending the ID of the target queue to the hardware accelerator;

[0110] The first data packet returned by the hardware accelerator according to the ID of the target queue is received, wherein the first data packet is a data packet in the target queue.

[0111] Optionally, in an embodiment, the determining module 601 is specifically configured to:

[0112] The identification ID of the target queue is obtained from the lock information corresponding to the critical section.

[0113] Optionally, in an embodiment, the transceiver module 603 is specifically used to:

[0114] The ID of the target queue and the second data packet are sent to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

[0115] Optionally, in one embodiment, the target queue is a first-in-first-out queue.

[0116] Optionally, in one embodiment, the transceiver module 603 is further used to:

[0117] Based on the fact that the first data packet is not obtained from the target queue, the step of obtaining the data packet from the target queue is repeated after waiting for a preset time until the first data packet is obtained.

[0118] It should be noted that the critical section execution device in the above NUMA system can save power for a NUMA in the NUMA system.

[0119] In hardware implementation, the above-mentioned determination module 601 and execution module 602 may be processors, and the transceiver module 603 may be a transceiver, or a module integrating a receiver and a transmitter, and the receiver and the transmitter may also constitute a communication interface.

[0120] Reference Figure 7 , Figure 7 A schematic diagram of the structure of a node in a NUMA system provided in an embodiment of the present application, such as Figure 7 As shown, a NUMA node in a NUMA system provided in an embodiment of the present application includes:

[0121] Processor 702, communication interface 703, memory 701 and bus 704. Processor 702, communication interface 703 and memory 701 are interconnected via bus 704. In an embodiment of the present application, processor 702 is used to control and manage the actions of nodes in the NUMA system. For example, processor 702 is used to support the execution of nodes in the NUMA system. Figure 3 The communication interface 703 is used to support the nodes in the NUMA system to communicate with other nodes. The memory 701 is used to store program codes and data in the nodes in the NUMA system.

[0122] Among them, the processor 702 can be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It can implement or execute various exemplary logic blocks, modules and circuits described in combination with the contents disclosed in this application. The processor 702 can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and so on. The bus 704 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0123] By calling the operation instruction stored in the memory 701, the processor 702 may run a first thread, and the processor 702 may perform the following steps:

[0124] Determine a target queue corresponding to the critical section, the NUMA system includes a plurality of nodes, each of which has at least one hardware queue, and the target queue is one of the hardware queues of the plurality of nodes;

[0125] Based on obtaining a first data packet from the target queue, the critical section is executed.

[0126] In some embodiments of the present application, the processor 702 further performs the following steps:

[0127] After executing the critical section, a second data packet is added to the target queue.

[0128] In some embodiments of the present application, the critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes.

[0129] In some embodiments of the present application, the processor 702 specifically performs the following steps:

[0130] Obtain the identification ID of the target queue corresponding to the critical section.

[0131] Calling the communication interface 703 to send the ID of the target queue to the hardware accelerator;

[0132] The first data packet returned by the hardware accelerator according to the ID of the target queue is received, wherein the first data packet is a data packet in the target queue.

[0133] In some embodiments of the present application, the processor 702 specifically performs the following steps:

[0134] The identification ID of the target queue is obtained from the lock information corresponding to the critical section.

[0135] In some embodiments of the present application, the processor 702 specifically performs the following steps:

[0136] The communication interface 703 is called to send the ID of the target queue and the second data packet to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

[0137] In some embodiments of the present application, the target queue is a first-in-first-out queue.

[0138] In some embodiments of the present application, the processor 702 further performs the following steps:

[0139] Based on the fact that the first data packet is not obtained from the target queue, the step of obtaining the data packet from the target queue is repeated after waiting for a preset time until the first data packet is obtained.

[0140] Reference Figure 8 , Figure 8 A schematic diagram of an embodiment of a NUMA system provided in an embodiment of the present application is shown in FIG. Figure 8 As shown in FIG, a NUMA system includes multiple interconnected NUMA nodes, each of which can execute Figure 2 The steps in the corresponding embodiments.

[0141] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0142] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0143] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0144] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0145] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, server, or other network device, etc.) to execute the present application. Figure 2 All or part of the steps of the method described in the embodiment. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0146] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A critical section execution method in a non-uniform memory access NUMA system, characterized in that: The method comprises: A first thread running on a node of the NUMA system determines a target queue corresponding to a critical section, the NUMA system includes a plurality of nodes, each of which has at least one hardware queue, the target queue is one of the hardware queues of the plurality of nodes, different critical sections correspond to different queues; the critical section uniquely corresponds to one of the hardware queues of the plurality of nodes; The first thread executes the critical section based on obtaining the first data packet from the target queue.

2. The method according to claim 1, characterized in that The method further comprises: After the first thread executes the critical section, the first thread adds a second data packet to the target queue.

3. The method according to claim 1 or 2, characterized in that: The first thread determines a target queue corresponding to the critical section, including: The first thread obtains an identification ID of a target queue corresponding to the critical section.

4. The method according to claim 3, characterized in that The method further comprises: The first thread sends the ID of the target queue to the hardware accelerator; The first thread receives the first data packet returned by the hardware accelerator according to the ID of the target queue, wherein the first data packet is a data packet in the target queue.

5. The method according to claim 3, characterized in that: The first thread obtains the identification ID of the target queue corresponding to the critical section, including: The first thread obtains the identification ID of the target queue from the lock information corresponding to the critical section.

6. The method according to claim 2, characterized in that The first thread adds the second data packet to the target queue, including: The first thread sends the ID of the target queue and the second data packet to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

7. The method according to claim 1 or 2, characterized in that: The target queue is a first-in-first-out queue.

8. The method according to claim 3, characterized in that The method further comprises: Based on the fact that the first thread fails to obtain the first data packet from the target queue, the first thread waits for a preset time and then repeats the step of obtaining the data packet from the target queue until the first data packet is obtained.

9. A critical section execution device in a NUMA system, characterized in that: The device comprises: a processor and a memory, wherein the processor is used to execute a program in the memory to execute the method described in any one of claims 1 to 8.

10. A critical section execution device in a NUMA system, characterized in that: The device comprises: A determination module, configured to determine a target queue corresponding to a critical section, wherein the NUMA system includes a plurality of nodes, wherein each node has at least one hardware queue, the target queue is one of the hardware queues of the plurality of nodes, and different critical sections correspond to different queues; the critical section uniquely corresponds to one of the hardware queues of the plurality of nodes; An execution module is used to execute the critical section based on obtaining a first data packet from the target queue.

11. The device according to claim 10, characterized in that The device also includes: The transceiver module is used to add the second data packet to the target queue after executing the critical section.

12. The device according to claim 10 or 11, characterized in that The determination module is specifically used for: Obtain the identification ID of the target queue corresponding to the critical section.

13. The device according to claim 12, characterized in that The device also includes a transceiver module, which is specifically used to: Sending the ID of the target queue to the hardware accelerator; The first data packet returned by the hardware accelerator according to the ID of the target queue is received, wherein the first data packet is a data packet in the target queue.

14. The device according to claim 12, characterized in that The determination module is specifically used for: The identification ID of the target queue is obtained from the lock information corresponding to the critical section.

15. The device according to claim 11, characterized in that The transceiver module is specifically used for: The ID of the target queue and the second data packet are sent to the hardware accelerator to instruct the hardware accelerator to add the second data packet to the target queue according to the ID of the target queue.

16. The device according to claim 10 or 11, characterized in that The target queue is a first-in-first-out queue.

17. The device according to claim 12, characterized in that The device also includes a transceiver module, which is also used for: Based on the fact that the first data packet is not obtained from the target queue, the step of obtaining the data packet from the target queue is repeated after waiting for a preset time until the first data packet is obtained.

18. A NUMA system, characterized in that: include: A plurality of nodes, at least one of the plurality of nodes is used to execute the method according to any one of claims 1 to 8.

Images