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, which reduces the number of lock contentions in the system and reduces the system resources consumed by the process of competing for locks. 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 a first 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 adds the ID of the first critical section to the target queue; a second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the first critical section.

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] Most current multi-processor computer systems provide shared resources for multiple threads, such as NUMA (nonuniform memory access architecture) systems. Some shared resources can only be used by one thread at a time. When multiple threads simultaneously execute the critical section of the same shared resource, resource conflicts will occur if mutual exclusive access control is not implemented.

[0003] When multiple threads in the system need to execute a critical section on the same shared resource, in order to prevent conflicts, each thread needs to compete for the spin lock corresponding to the critical section 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 protected by the spin lock.

[0004] However, if there are a large number of threads in the system that need to compete for the same spin lock, the system will generate a large number of operations to compete for the lock. The process of competing for the lock will consume a lot of system resources and greatly reduce the performance of the system. Summary of the invention

[0005] The present application provides a critical section execution method and device in a NUMA system, which reduces the number of lock contentions in the system and reduces the system resources consumed by the process of lock contention.

[0006] In the first aspect, 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 first critical section, the NUMA system comprises multiple nodes, each node having at least one hardware queue, and the target queue is one of the hardware queues of the multiple nodes; the first thread adds an identification ID of the first critical section to the target queue; a second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the first critical section.

[0007] Through the above method, the first thread can add the first critical section to the target queue, the second thread can obtain the ID of the first critical section in the target queue, and execute the first critical section according to the ID of the first critical section. In the scenario of the NUMA system, when multiple threads execute the critical section concurrently, each thread does not need to compete for the lock of the critical section, thereby reducing the system resources consumed by the process of competing for the lock.

[0008] In an optional design of the first aspect, the target queue is a hardware queue on a node running the second thread. In this way, since the second thread can obtain the first critical section from a local target queue on the node, the delay in obtaining the critical section can be reduced.

[0009] In an optional design of the first aspect, the critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes. The critical section uniquely corresponds to one hardware queue, which can ensure atomic execution of the critical section.

[0010] In an optional design of the first aspect, the first thread determines the target queue corresponding to the first critical section, including: the first thread obtains the identification ID of the target queue corresponding to the first critical section. Each node has at least one hardware queue, and each hardware queue may correspond to the ID of a target queue, wherein the ID of the target queue may include the ID of the node where the target queue is located and the queue ID of the target queue in 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.

[0011] In an optional design of the first aspect, the first thread determines the target queue corresponding to the first critical section, including: the first thread determines the target queue corresponding to the critical section according to a preconfigured corresponding relationship.

[0012] In an optional design of the first aspect, the first thread adds the first critical section to the target queue, including: the first thread sends the ID of the first critical section and the ID of the target queue to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0013] In an optional design of the first aspect, the method further includes: after the first thread adds the first critical section to the target queue, the first thread enters a sleep state; after the second thread executes the first critical section, the second thread wakes up the first thread.

[0014] In an optional design of the first aspect, the method further includes: a third thread running on a node of the NUMA system determines that the second critical section corresponds to the target queue; the third thread adds the ID of the second critical section to the target queue; the second thread obtains the ID of the second critical section from the target queue; after the second thread completes the execution of the first critical section, the second thread executes the second critical section according to the ID of the second critical section. In this way, the second thread does not execute different critical sections protected by the same lock at the same time, thereby ensuring the atomic execution of the critical sections.

[0015] In an optional design of the first aspect, the moment when the ID of the second critical section joins the target queue is later than the moment when the ID of the first critical section joins the target queue. Through the above method, the fairness of critical section execution can be guaranteed, and the situation where the critical section that joins the target queue first is executed later than the critical section that joins the target queue later will not occur.

[0016] In second aspect, an embodiment of the present application provides a critical section execution method in a NUMA system, including: a first thread running on a first node of the NUMA system determines a target queue corresponding to a first critical section, the first node has at least one hardware queue, and the target queue is one of the at least one hardware queue; the first thread adds the ID of the first critical section to the target queue; based on a second thread running on the first node acquiring a lock, the second thread acquires the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the first critical section.

[0017] Through the above method, the first thread can add the first critical section to the target queue of the first node. After obtaining the lock of the target queue, the second thread in the first node can obtain the ID of the first critical section and execute the first critical section according to the ID of the first critical section, so that there is only competition for each target queue in the NUMA system, and there is no need for the thread to compete for the lock of the critical section every time it executes the critical section, which reduces the number of lock competitions in the NUMA system and reduces the overhead caused by lock competition.

[0018] In an optional design of the second aspect, the NUMA system includes multiple nodes, each of the multiple nodes includes a target queue, the lock corresponds to the multiple target queues included in the multiple nodes, and the lock is used to control the access of each of the multiple nodes to the target queue it has.

[0019] In an optional design of the second aspect, the target queue is a hardware queue in the first node.

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

[0021] In an optional design of the second aspect, the first thread determines the target queue corresponding to the first critical section, including: the first thread obtains an identification ID of the target queue corresponding to the first critical section.

[0022] In an optional design of the second aspect, the first thread adds the ID of the first critical section to the target queue, including: the first thread sends the ID of the first critical section and the ID of the target queue to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0023] In an optional design of the second aspect, the method further includes: after the first thread adds the first critical section to the target queue, the first thread enters a sleep state; after the second thread executes the first critical section, the second thread wakes up the first thread.

[0024] In an optional design of the second aspect, the method also includes: a third thread running on the first node determines that the second critical section corresponds to the target queue; the third thread adds the ID of the second critical section to the target queue; the second thread obtains the ID of the second critical section from the target queue; after completing the execution of the first critical section, the second thread executes the second critical section according to the ID of the second critical section.

[0025] In an optional design of the second aspect, the time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

[0026] In a third aspect, the present application provides a critical section execution device in a NUMA system, the device comprising: a processor and a memory, the processor being used to execute code in the memory to implement the method described in the first aspect or the second aspect above.

[0027] In a fourth aspect, the present application provides a NUMA system, including: a first node and a second node, wherein the first node and the second node each have at least one hardware queue;

[0028] The first node is used to determine a target queue corresponding to the first critical section, and add the ID of the first critical section to the target queue; the target queue is one of the hardware queues of the first node and the second node;

[0029] The second node is used to obtain the ID of the first critical section from the target queue, and execute the first critical section according to the ID of the first critical section.

[0030] In an optional design of the fourth aspect, the target queue is a hardware queue on the second node.

[0031] In an optional design of the fourth aspect, the critical section uniquely corresponds to one of the hardware queues of the first node and the second node.

[0032] In an optional design of the fourth aspect, the first node is specifically configured to:

[0033] Obtain an identification ID of a target queue corresponding to the first critical section.

[0034] In an optional design of the fourth aspect, the first node is specifically configured to:

[0035] The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0036] In an optional design of the fourth aspect, the first node is further configured to:

[0037] Determining that a second critical section corresponds to the target queue, and adding the second critical section to the target queue;

[0038] The second node is further configured to obtain the second critical section from the target queue, and after completing the execution of the first critical section, execute the second critical section according to the ID of the second critical section.

[0039] In an optional design of the fourth aspect, the time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

[0040] In a fifth aspect, the present application provides a critical section execution device in a NUMA system, the device comprising:

[0041] A determination module, configured to determine a target queue corresponding to the first critical section, the NUMA system comprising a plurality of nodes, wherein each node has at least one hardware queue, and the target queue is one of the hardware queues of the plurality of nodes;

[0042] A transceiver module, configured to add the ID of the first critical section to the target queue; and obtain the ID of the first critical section from the target queue;

[0043] An execution module is used to execute the first critical section according to the ID of the first critical section.

[0044] In an optional design of the fifth aspect, the first critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes.

[0045] In a sixth aspect, the present application provides a critical section execution device in a NUMA system, the device comprising:

[0046] A determination module, configured to determine a target queue corresponding to the first critical section, the NUMA system comprising a plurality of nodes, wherein each node has at least one hardware queue, and the target queue is one of the hardware queues of the plurality of nodes;

[0047] A transceiver module, configured to add the ID of the first critical section to the target queue; and based on acquiring the lock, obtain the ID of the first critical section from the target queue;

[0048] An execution module is used to execute the first critical section according to the ID of the first critical section.

[0049] In an optional design of the sixth aspect, each of the multiple nodes includes a target queue, the lock corresponds to the multiple target queues included in the multiple nodes, and the lock is used to control the access of each of the multiple nodes to the target queues it has.

[0050] In an optional design of the sixth aspect, the target queue is a hardware queue in the first node.

[0051] In an optional design of the sixth aspect, the first critical section uniquely corresponds to one hardware queue among the hardware queues of the multiple nodes.

[0052] In an optional design of the sixth aspect, the determining module is specifically configured to:

[0053] The target queue corresponding to the critical section is determined according to the pre-configured correspondence.

[0054] In an optional design of the sixth aspect, the determining module is specifically configured to:

[0055] Obtain an identification ID of a target queue corresponding to the first critical section.

[0056] In an optional design of the sixth aspect, the transceiver module is specifically used to:

[0057] The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0058] In an optional design of the sixth aspect, the determining module is further used to:

[0059] determining that a second critical section corresponds to the target queue;

[0060] The transceiver module is further used to add the ID of the second critical section to the target queue; and obtain the ID of the second critical section from the target queue;

[0061] The execution module is further configured to execute the second critical section according to the ID of the second critical section after completing the execution of the first critical section.

[0062] In an optional design of the sixth aspect, the time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

[0063] 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 first 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 adds the ID of the first critical section to the target queue; a second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the first critical section. In the above manner, the first thread can add the first critical section to the target queue, the second thread can obtain the ID of the first critical section, and execute the first critical section according to the ID of the first critical section. In the scenario of the NUMA system, when multiple threads execute the critical section concurrently, each thread does not need to compete for the lock of the critical section, thereby reducing the system resources consumed by the process of competing for the lock. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0067] Figures 4a to 4f A schematic diagram of a critical section execution according to an embodiment of the present application;

[0068] Figure 5A schematic diagram of the structure of a NUMA system provided in an embodiment of the present application;

[0069] 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;

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

[0071] Figure 8 A schematic diagram of the structure of a node in a NUMA system provided in an embodiment of the present application;

[0072] Fig. 9 A schematic diagram of an embodiment of a NUMA system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] 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.

[0074] 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.

[0075] 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, which can be used to install a CPU socket. The socket 101a and the socket 101b may be collectively referred to as a socket 101 herein. 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.

[0076] The slot 101 may include multiple nodes, each of which has its own central processing unit (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.

[0077] 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 the shared resources can be called a critical section. When different threads in the NUMA system 100 access shared 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 critical section of the same shared resource can only be executed by one thread. Specifically, a lock can be used to protect the critical section. Multiple threads need to apply for a lock before executing a critical section on the same shared resource. Only the thread holding the lock can execute the critical section, and the lock is released after the critical section is executed.

[0078] 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}.

[0079] 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.

[0080] 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}.

[0081] 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.

[0082] 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.

[0083] In the prior art, if there are n threads in a NUMA system that need to execute a critical section protected by a lock, then at least n competitive spin lock operations are required in the NUMA system. For processors with advanced reduced instruction set machine (ARM) architecture, the number of processor cores is large, so the number of threads concurrently competing for the same lock may be large. Therefore, when the above-mentioned competitive spin lock method is applied to a system with an ARM architecture processor, a large number of competitive lock operations will be generated in the system, and the process of competing for the lock will consume a large amount of system resources. In addition, the single-core processing speed of the ARM architecture processor is lower, and a large number of competitive lock operations greatly reduce the performance of the ARM architecture processor.

[0084] In order to solve the above problems, the present application provides a critical section execution method in a NUMA system, referring to Figure 2 , Figure 2 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 2 As shown, the critical section execution method in the NUMA system provided by the present application specifically includes:

[0085] 201. A first thread running on a node of the NUMA system determines a target queue corresponding to a first 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.

[0086] In the embodiment of the present application, the NUMA system may include multiple 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.

[0087] In one embodiment, the physical queue may be a (packet order enforcer, POE) hardware queue, which is a first-in, first-out queue located in the CPU of each NUMA node. For example, the POE queue may be located in a node-specific SRAM, and the atomicity of adding and retrieving packets from the queue is guaranteed by the POE hardware. A NUMA node may have multiple POE hardware queues, for example, 768 POE hardware queues. The delays of adding and retrieving packets from the POE hardware queue are both less than the delay caused by accessing the memory.

[0088] 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.

[0089] 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.

[0090] 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 only one hardware queue in the NUMA system.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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).

[0096] 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.

[0097] 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.

[0098] 202. The first thread adds the identification ID of the first critical section to the target queue.

[0099] In an embodiment of the present application, after a first thread running on a node of the NUMA system determines a target queue corresponding to a first critical section, the first thread may add an identification ID of the first critical section to the target queue.

[0100] It should be noted that the ID of the critical section in the embodiment of the present application is an identifier that can uniquely point to the critical section. Based on the identifier of the critical section, the thread can determine the address of the critical section in the memory, and then load and execute the critical section according to the address.

[0101] Exemplarily, the ID of the critical section may be a task pointer of the critical section, that is, a pointer pointing to the address of the critical section.

[0102] Optionally, after the first thread obtains the ID of the target queue corresponding to the critical section, the first thread may send the identification ID of the first critical section and the ID of the target queue to the hardware accelerator, so that the hardware accelerator adds the identification ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0103] In an embodiment of the present application, the ID of the target queue may be the queue ID of the target queue, wherein the queue ID may be the number of the queue.

[0104] In an embodiment of the present application, a corresponding hardware accelerator may be provided on each node in the server, and each hardware accelerator may maintain a hardware queue in a local node. In an embodiment of the present application, the first thread may obtain the node ID of the node where the target queue is located, and route to the hardware accelerator in the corresponding node through the obtained node ID, and send the queue ID of the target queue and the ID of the first critical section to the hardware accelerator. The hardware accelerator may receive the queue ID and the first critical section of the target queue, and add the ID of the first critical section to the target queue.

[0105] It should be noted that if the target queue corresponding to the critical section is a local queue of the target node, the queue ID of the target queue and the ID of the first critical section may be directly sent to the local hardware accelerator.

[0106] Optionally, in one embodiment, the hardware accelerator may provide a first interface for receiving the queue ID of the target queue and the ID of the first critical section sent by the first thread, and adding the ID of the first critical section to the target queue corresponding to the queue ID of the target queue.

[0107] It should be noted that the description of the above interface is only for illustration, and in actual applications, interfaces with other functions may also be deployed on the hardware accelerator.

[0108] Optionally, in an embodiment of the present application, the first thread may send a task pointer of the first critical section to the hardware accelerator. Accordingly, the hardware accelerator may add the task pointer of the first critical section to the corresponding target queue. The task pointer indicates the address of the first critical section. The second thread may determine the address of the first critical section in the memory by obtaining the task pointer from the target queue, and then load and execute the first critical section according to the address.

[0109] In an embodiment of the present application, multiple threads in a NUMA system can run to the critical section protected by the same lock in turn, and the multiple threads can determine the target queue corresponding to the critical section in turn, and enable the threads to add the ID of the critical section to the corresponding target queue in turn. For example, when the third thread running in the NUMA system runs to the second critical section, the third thread determines that the critical section corresponds to the target queue, and adds the ID of the second critical section to the target queue.

[0110] Optionally, in one embodiment, the first thread adds the ID of the first critical section to the first element of the target queue, and the third thread may add the ID of the second critical section to the second element of the target queue, wherein the first element and the second element are different elements in the target queue. That is, the IDs of different critical sections protected by the same lock may be added to different elements of the target queue.

[0111] In the embodiment of the present application, after the first thread adds the ID of the first critical section to the target queue, the first thread can enter a sleep state. Regarding how the first thread enters a sleep state, reference can be made to the implementation method of the prior art, which will not be repeated here.

[0112] 203. A second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue.

[0113] In the embodiment of the present application, the second thread can obtain the ID of the first critical section from the target queue. The second thread can be located on the same node as the first thread, or on a different node from the first thread.

[0114] In the embodiment of the present application, each target queue in the NUMA system may uniquely correspond to one second thread, and accordingly, the second thread running on a node of the NUMA system may obtain the first critical section from the corresponding target queue.

[0115] Optionally, in an embodiment, the hardware accelerator may provide a second interface, and the second thread may obtain the ID of the first critical section included in the corresponding target queue through the second interface.

[0116] Optionally, the second thread may obtain the ID of the first critical section from the target queue every preset time period.

[0117] In one embodiment, after the third thread adds the ID of the second critical section to the target queue, the target queue includes the ID of the first critical section and the ID of the second critical section. At this time, the second thread obtains the ID of the first critical section and the ID of the second critical section from the target queue through the second interface of the hardware accelerator.

[0118] In one embodiment, after the third thread adds the ID of the second critical section to the target queue, the target queue includes the ID of the first critical section and the ID of the second critical section. At this time, the second thread obtains the ID of the first critical section from the target queue through the second interface of the hardware accelerator, and after the first critical section is executed, obtains the ID of the second critical section from the target queue through the second interface of the hardware accelerator.

[0119] Optionally, in one embodiment, if the critical sections protected by the same lock are added to different elements of the target queue, for example, the first element in the target queue includes the ID of the first critical section, and the second element in the target queue includes the ID of the second critical section, the second thread can obtain the ID of the first critical section in the first element and the ID of the second critical section in the second element sequentially or simultaneously through the second interface of the hardware accelerator.

[0120] In the embodiment of the present application, the target queue is a hardware queue on the node on which the second thread is running.

[0121] In the embodiment of the present application, since the second thread can obtain the ID of the first critical section from the local target queue on the node where it is located, the delay in obtaining the critical section can be reduced.

[0122] 204. The second thread executes the first critical section according to the ID of the second critical section.

[0123] In the embodiment of the present application, after obtaining the ID of the first critical section, the second thread may execute the first critical section according to the ID of the first critical section.

[0124] Optionally, in an embodiment, after obtaining the ID of the first critical section, the second thread may determine the address of the first critical section in the memory according to the ID of the first critical section, and then load and execute the first critical section according to the address.

[0125] In one embodiment, after the second thread obtains the ID of the second critical section of the target queue, the second critical section may be executed according to the ID of the second critical section.

[0126] In the embodiment of the present application, the second thread executes the second critical section after completing the execution of the first critical section. That is, in the embodiment, the second thread does not execute different critical sections protected by the same lock at the same time, thereby ensuring the atomic execution of the critical sections.

[0127] In the embodiment of the present application, after the second thread completes executing the first critical section, the second thread may wake up the first thread.

[0128] Optionally, in one embodiment, the target queue is a first-in-first-out (FIFO) queue.

[0129] In an embodiment of the present application, the first thread adds the ID of the first critical section to the target queue at a first moment, and the first thread adds the ID of the second critical section to the target queue at a second moment, wherein the first moment is before the second moment.

[0130] In the embodiment of the present application, the second thread obtains the ID of the second critical section from the target queue at the third time, and the second thread obtains the ID of the second critical section from the target queue at the fourth time, and the third time is before the fourth time. This is equivalent to the second thread first obtaining the ID of the first critical section that was first added to the target queue, and then obtaining the ID of the second critical section of the target queue.

[0131] Optionally, the second thread may first obtain the ID of the first critical section that is first added to the target queue, and after completing the execution of the first critical section, obtain the ID of the second critical section of the target queue, and then execute the second critical section. In this way, the fairness of critical section execution can be guaranteed, and the situation where the ID of the critical section that is first added to the target queue is executed later than the critical section that is later added to the target queue will not occur.

[0132] 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 first 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 adds the ID of the first critical section to the target queue; a second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the first critical section. In the above manner, the first thread can add the ID of the first critical section to the target queue, the second thread can obtain the ID of the first critical section, and execute the first critical section according to the ID of the first critical section. In the scenario of the NUMA system, when multiple threads execute the critical section concurrently, each thread does not need to compete for the lock of the critical section, thereby reducing the system resources consumed by the process of competing for the lock.

[0133] Reference Figure 3 , Figure 3 A schematic diagram of another critical section execution method in a NUMA system provided in an embodiment of the present application, such as Figure 3 As shown in the figure, the present application provides a method for accessing critical resources, which specifically includes:

[0134] 301. A first thread running on a first node of the NUMA system determines a target queue corresponding to a first critical section, the first node having at least one hardware queue, and the target queue is one of the at least one hardware queue.

[0135] In an embodiment of the present application, the NUMA system may include multiple interconnected nodes, each node may include at least one hardware queue, and each lock may be bound to a hardware queue in each node, that is, each lock may correspond to a hardware queue in each node.

[0136] In the embodiment of the present application, when the database is started and initialized, the lock and the hardware queue can be bound first. Specifically, for the critical section that needs to be executed atomically, a lock needs to be set for protection. In this embodiment, each lock can be bound to each critical section that needs to be executed atomically. Specifically, each lock can be bound to a hardware queue in the node, which is equivalent to establishing a binding relationship between each critical section that needs to be executed atomically and the hardware queue.

[0137] In an embodiment of the present application, each lock corresponds to a critical section. If a thread on a node is about to execute a critical section, the hardware queue corresponding to the critical section can be determined through the binding relationship between the above-mentioned critical section (lock) and the hardware queue, wherein the determined hardware queue is the hardware queue corresponding to the node.

[0138] In an embodiment of the present application, a first node running in a NUMA system may include multiple hardware queues, each of which may correspond to an identification ID of a target queue, wherein the ID of the target queue may include the queue ID of the target queue in the node where it is located. Specifically, the queue ID of the bound hardware queue may be recorded in the lock information of each lock. If the first thread of the first node is about to execute the first critical section, the first thread may query the lock information corresponding to the first critical section, and obtain the queue ID corresponding to the first critical section from the corresponding lock information.

[0139] Next, a schematic diagram of the process of binding a lock to a hardware queue is described. Exemplarily, the first node includes m hardware queues (queue 1 to queue m), the NUMA system includes m locks (lock 1 to lock m), lock 1 is bound to queue 1, that is, (queue 1) is recorded in the lock information of lock 1, and the binding of lock 1 to queue 1 is completed, and by analogy, the remaining m-1 locks are bound to the remaining hardware queues. Correspondingly, the critical sections on node 1 that lock 1 needs to protect all correspond to queue 1.

[0140] In the embodiment of the present application, the third thread running on the first node may also determine that the second critical section corresponds to the target queue.

[0141] 302. The first thread adds the ID of the first critical section to the target queue.

[0142] The specific description of step 302 can be found in Figure 2 The description of step 202 in the corresponding embodiment will not be repeated here.

[0143] 303. Based on the second thread running on the first node acquiring the lock, the second thread acquires the ID of the first critical section from the target queue.

[0144] and Figure 2 What is different from the corresponding embodiments is that, in the embodiments of the present application, since each node of the NUMA system includes a target queue corresponding to the critical section, the second thread needs to compete in the NUMA system for the mutex locks corresponding to the multiple target queues included in the NUMA system. The mutex lock can control the access to the respective target queues in each node in the NUMA system. Through the above method, for the critical section protected by the same lock, the system has only one thread executing.

[0145] In one embodiment, the aforementioned lock is a mutex lock. Specifically, at least one linked list can be maintained in the shared memory of the NUMA system, each linked list corresponds to a target queue, and the thread that obtains the aforementioned mutex lock is located at the head of the linked list, indicating the thread currently executing the corresponding critical section. The thread at the head of the linked list will be serially connected to other threads, indicating the order in which the threads execute the critical section. If the thread currently at the head completes the critical section, the next thread will be awakened through the next pointer. At this time, if other threads need to execute the critical section corresponding to the linked list, they will be added to the tail of the linked list.

[0146] Optionally, in one embodiment, a global pointer can be set in the linked list to point to the tail of the current linked list. The head of the linked list is the currently running thread. If a thread wants to join the execution queue, the compare-and-swap function can be used to atomically make the global pointer point to itself, and at the same time point the Next pointer at the tail of the currently running thread to itself, that is, atomically join the execution queue. After each thread is executed, the next thread to be executed is awakened through the Next pointer, thereby completing the global uniqueness of the critical section execution.

[0147] In one embodiment, the aforementioned lock is a spin lock.

[0148] Exemplarily, a NUMA system may include a first node and a second node, wherein the first node runs a first thread and a second thread, and the second node runs a fourth thread and a fifth thread, the first thread and the fourth thread both include critical sections that require protection by the same lock (the first thread includes a first critical section, and the fourth thread includes a fourth critical section), the first node has a target queue 1 corresponding to the first critical section, and the second node has a target queue 2 corresponding to the fourth critical section.

[0149] In an embodiment of the present application, the first thread can determine the target queue 1 corresponding to the first critical section before executing the first critical section, and add the ID of the first critical section to the target queue 1; the fourth thread can determine the target queue 2 corresponding to the fourth critical section before executing the fourth critical section, and add the ID of the fourth critical section to the target queue 2.

[0150] The second thread and the fifth thread compete for the locks corresponding to the target queue 1 and the target queue 2. If the second thread obtains the lock, the second thread obtains the ID of the first critical section from the target queue 1, executes the first critical section, and releases the lock. At this time, the fifth thread obtains the lock, obtains the ID of the fourth critical section from the target queue 2, executes the fourth critical section, and releases the lock.

[0151] 304. The second thread executes the first critical section according to the ID of the first critical section.

[0152] The specific description of step 304 can be found in Figure 2 The description of step 204 in the corresponding embodiment will not be repeated here.

[0153] In an embodiment of the present application, a first thread running on a first node of the NUMA system determines a target queue corresponding to a first critical section, the first node has at least one hardware queue, and the target queue is one of the at least one hardware queue; the first thread adds the ID of the first critical section to the target queue; based on the second thread running on the first node obtaining a lock, the second thread obtains the ID of the first critical section from the target queue; the second thread executes the first critical section according to the ID of the local first critical section. In the above manner, the first thread can add the first critical section to the target queue of the first node, and the second thread in the first node can obtain the ID of the first critical section after obtaining the lock of the target queue, and execute the first critical section according to the ID of the first critical section, so that there is only competition for each target queue in the NUMA system, and there is no need for threads to compete for the lock of the critical section every time they execute the critical section, which reduces the number of lock competitions in the NUMA system and reduces the overhead caused by lock competitions.

[0154] Reference Figures 4a to 4f , Figures 4a to 4f This is a schematic diagram of a critical section execution in an embodiment of the present application. In the embodiment of the present application, thread 1, thread 2, and thread 3 include a critical section that requires protection by the same lock. Thread 1 and thread 2 are threads running on node 1, thread 3 is a thread running on node 2, thread 4 is also running on the first node, and thread 5 is also running on the second node. Node 1 has physical queues 0 to physical queue N, and node 2 has physical queues 0 to physical queue N.

[0155] like Figure 4aAs shown in , when thread 1 is about to execute critical section 1, the ID of critical section 1 is added to physical queue 0 in node 1. Specifically, thread 1 can obtain the ID of the corresponding physical queue (physical queue 0) from the lock information corresponding to critical section 1 to be executed, thread 1 can send the identifiers of critical section 1 and the physical queue (physical queue 0) to the hardware accelerator, and the hardware accelerator can add the ID of critical section 1 to physical queue 0 based on the identifier of the physical queue (physical queue 0) sent by thread 1. Similarly, when thread 2 is about to execute critical section 2, the ID of critical section 2 is added to physical queue 0 in node 1. Similarly, when thread 3 is about to execute critical section 3, the ID of critical section 3 is added to physical queue 0 in node 2.

[0156] At the same time, threads 4 and 5 compete for the lock.

[0157] like Figure 4b As shown in , thread 4 acquires the lock and thread 5 is in the state of waiting for the lock.

[0158] like Figure 4c As shown in , thread 4 obtains the ID of critical section 1 and the ID of critical section 2 in physical queue 0 of node 1, and executes critical section 1 and critical section 2.

[0159] like Figure 4d As shown in FIG, after thread 4 completes executing critical section 1 and critical section 2, it releases the lock.

[0160] like Figure 4e As shown in , thread 5 acquires the lock, obtains the ID of critical section 3 in physical queue 0 of node 2, and executes critical section 3.

[0161] like Figure 4f As shown in , thread 4 releases the lock.

[0162] 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 5 , Figure 5 A structural diagram of a NUMA system provided in an embodiment of the present application is shown in FIG. Figure 5 As shown in , a NUMA system provided by an embodiment of the present application includes: a first node 501 and a second node 502, wherein the first node and the second node each have at least one hardware queue;

[0163] The first node 501 is used to determine a target queue corresponding to the first critical section, and add the ID of the first critical section to the target queue; the target queue is one of the hardware queues of the first node and the second node;

[0164] The second node 502 is used to obtain the ID of the first critical section from the target queue, and execute the first critical section according to the ID of the first critical section.

[0165] Optionally, in one embodiment, the target queue is a hardware queue on the second node 502 .

[0166] Optionally, in an embodiment, the critical section uniquely corresponds to one of the hardware queues of the first node 501 and the second node 502 .

[0167] Optionally, in an embodiment, the first node 501 is specifically configured to:

[0168] The target queue corresponding to the critical section is determined according to the pre-configured correspondence.

[0169] Optionally, in an embodiment, the first node 501 is specifically configured to:

[0170] Obtain an identification ID of a target queue corresponding to the first critical section.

[0171] Optionally, in an embodiment, the first node 501 is specifically configured to:

[0172] The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0173] Optionally, in an embodiment, the first node 501 is further configured to:

[0174] Determining that a second critical section corresponds to the target queue, and adding the second critical section to the target queue;

[0175] The second node 502 is further configured to obtain the second critical section from the target queue, and execute the second critical section according to the ID of the second critical section after completing the execution of the first critical section.

[0176] Optionally, in an embodiment, the time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

[0177] Reference 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, Figure 6 The critical section execution device in the NUMA system shown in FIG. 1 may be a NUMA node, such as Figure 6As shown in FIG. 1 , a critical section execution device in a NUMA system provided by an embodiment of the present application includes:

[0178] A determination module 601 is used to determine a target queue corresponding to a first 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;

[0179] The transceiver module 602 is used to add the ID of the first critical section to the target queue; and obtain the ID of the first critical section from the target queue;

[0180] The execution module 603 is configured to execute the first critical section according to the ID of the first critical section.

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

[0182] Reference Figure 7 , Figure 7 A schematic diagram of the structure of a critical section execution device in a NUMA system provided in an embodiment of the present application, Figure 7 The critical section execution device in the NUMA system shown in FIG. 1 may be a NUMA node, such as Figure 7 As shown in FIG. 1 , a critical section execution device in a NUMA system provided by an embodiment of the present application includes:

[0183] A determination module 701 is used to determine a target queue corresponding to a first 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;

[0184] The transceiver module 702 is used to add the ID of the first critical section to the target queue; based on the lock obtained, obtain the ID of the first critical section from the target queue;

[0185] The execution module 703 is configured to execute the first critical section according to the ID of the first critical section.

[0186] Optionally, in one embodiment, each of the multiple nodes includes a target queue, the mutex lock corresponds to the multiple target queues included in the multiple nodes, and the mutex lock is used to control the access of each of the multiple nodes to the respective target queue.

[0187] Optionally, in one embodiment, the target queue is a hardware queue in the first node.

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

[0189] Optionally, in an embodiment, the determining module 701 is specifically configured to:

[0190] Obtain an identification ID of a target queue corresponding to the first critical section.

[0191] Optionally, in an embodiment, the transceiver module 702 is specifically configured to:

[0192] The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

[0193] Optionally, in an embodiment, the determining module 701 is further configured to:

[0194] determining that a second critical section corresponds to the target queue;

[0195] The transceiver module 702 is further configured to add the ID of the second critical section to the target queue; and obtain the ID of the second critical section from the target queue;

[0196] The execution module 703 is further configured to execute the second critical section according to the ID of the second critical section after completing the execution of the first critical section.

[0197] Optionally, in an embodiment, the time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

[0198] In hardware implementation, the above-mentioned determination module 601, determination module 701, execution module 603 and execution module 703 can be processor modules, the transceiver module 602 and transceiver module 702 can be transceivers, or modules integrating the receiver and the transmitter, and the receiver and the transmitter can also constitute a communication interface.

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

[0200] Processor 802, communication interface 803, memory 801 and bus 804. Processor 802, communication interface 803 and memory 801 are interconnected via bus 804. In an embodiment of the present application, processor 802 is used to control and manage the actions of nodes in the NUMA system. For example, processor 802 is used to support the execution of nodes in the NUMA system. Figure 2 Steps 201 to 204, and Figure 3 The communication interface 803 is used to support the nodes in the NUMA system to communicate with other nodes. The memory 801 is used to store program codes and data in the nodes in the NUMA system.

[0201] Among them, the processor 802 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 802 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 804 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 8 Only 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.

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

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] 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 or Figure 3 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.

[0208] 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 first 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, the first critical section is a critical section to be executed, and the first critical section uniquely corresponds to one of the hardware queues of the plurality of nodes; The first thread adds the identification ID of the first critical section to the target queue; A second thread running on a node of the NUMA system obtains the ID of the first critical section from the target queue; The second thread executes the first critical section according to the ID of the first critical section.

2. The method according to claim 1, characterized in that The target queue is a hardware queue on a node on which the second thread is running.

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

4. The method according to claim 3, characterized in that The first thread adds the first critical section to the target queue, including: The first thread sends the ID of the first critical section and the ID of the target queue to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: After the first thread adds the first critical section to the target queue, the first thread enters a sleep state; After the second thread executes the first critical section, the second thread wakes up the first thread.

6. The method according to claim 1 or 2, characterized in that: The method further comprises: A third thread running on a node of the NUMA system determines that a second critical section corresponds to the target queue; The third thread adds the ID of the second critical section to the target queue; The second thread obtains the ID of the second critical section from the target queue; After completing the execution of the first critical section, the second thread executes the second critical section according to the ID of the second critical section.

7. The method according to claim 6, characterized in that The time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

8. A critical section execution method in a NUMA system, characterized in that: The method comprises: A first thread running on a first node of the NUMA system determines a target queue corresponding to a first critical section, the first node has at least one hardware queue, the target queue is one of the at least one hardware queue, the first critical section is a critical section to be executed, the NUMA system includes a plurality of nodes, and the first critical section uniquely corresponds to a hardware queue among the hardware queues of the plurality of nodes; The first thread adds the ID of the first critical section to the target queue; Based on the second thread running on the first node acquiring the lock, the second thread acquires the ID of the first critical section from the target queue; The second thread executes the first critical section according to the ID of the first critical section.

9. The method according to claim 8, characterized in that Each of the multiple nodes includes a target queue, the lock corresponds to the multiple target queues included in the multiple nodes, and the lock is used to control the access of each of the multiple nodes to the target queues respectively owned by the node.

10. The method according to claim 8 or 9, characterized in that: The target queue is a hardware queue in the first node.

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

12. The method according to claim 8, characterized in that The first thread adds the ID of the first critical section to the target queue, including: The first thread sends the ID of the first critical section and the ID of the target queue to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

13. The method according to claim 8 or 9, characterized in that: The method further comprises: After the first thread adds the ID of the first critical section to the target queue, the first thread enters a sleep state; After the second thread executes the first critical section, the second thread wakes up the first thread.

14. The method according to claim 8 or 9, characterized in that: The method further comprises: A third thread running on the first node determines that the second critical section corresponds to the target queue; The third thread adds the ID of the second critical section to the target queue; The second thread obtains the ID of the second critical section from the target queue; After completing the execution of the first critical section, the second thread executes the second critical section according to the ID of the second critical section.

15. The method according to claim 14, characterized in that The time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

16. A critical section execution device in a non-uniform memory access NUMA system, characterized in that: The device comprises: a processor and a memory, wherein the processor is configured to execute a code in the memory to implement the method according to any one of claims 1 to 15.

17. A non-uniform memory access NUMA system, characterized in that: include: a first node and a second node, each of the first node and the second node having at least one hardware queue; The first node is used to determine a target queue corresponding to a first critical section, and add an ID of the first critical section to the target queue; the target queue is one of the hardware queues of the first node and the second node, the first critical section is a critical section to be executed, and the first critical section uniquely corresponds to one of the hardware queues of the first node and the second node; The second node is used to obtain the ID of the first critical section from the target queue, and execute the first critical section according to the ID of the first critical section.

18. The NUMA system according to claim 17, characterized in that: The target queue is a hardware queue on the second node.

19. The NUMA system according to claim 17 or 18, characterized in that: The first node is specifically used for: Obtain an identification ID of a target queue corresponding to the first critical section.

20. The NUMA system according to claim 19, characterized in that: The first node is specifically used for: The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

21. The NUMA system according to claim 17 or 18, characterized in that: The first node is further configured to: Determining that a second critical section corresponds to the target queue, and adding the second critical section to the target queue; The second node is further configured to obtain the second critical section from the target queue, and after completing the execution of the first critical section, execute the second critical section according to the ID of the second critical section.

22. The NUMA system according to claim 21, characterized in that: The time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

23. A critical section execution device in a non-uniform memory access NUMA system, characterized in that: The device comprises: A determination module, configured to determine a target queue corresponding to a first critical section, the NUMA system comprising 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, the first critical section is a critical section to be executed, and the first critical section uniquely corresponds to one of the hardware queues of the plurality of nodes; A transceiver module, configured to add the ID of the first critical section to the target queue; and obtain the ID of the first critical section from the target queue; An execution module is used to execute the first critical section according to the ID of the first critical section.

24. A critical section execution device in a non-uniform memory access NUMA system, characterized in that: The device comprises: A determination module, configured to determine a target queue corresponding to a first critical section, the NUMA system comprising 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, the first critical section is a critical section to be executed, and the first critical section uniquely corresponds to one of the hardware queues of the plurality of nodes; A transceiver module, configured to add the ID of the first critical section to the target queue; and based on acquiring the lock, obtain the ID of the first critical section from the target queue; An execution module is used to execute the first critical section according to the ID of the first critical section.

25. The device according to claim 24, characterized in that Each of the multiple nodes includes a target queue, the lock corresponds to the multiple target queues included in the multiple nodes, and the lock is used to control the access of each of the multiple nodes to the target queues respectively owned by the node.

26. The device according to claim 24 or 25, characterized in that The target queue is a hardware queue in the first node.

27. The device according to claim 24 or 25, characterized in that The determination module is specifically used for: Obtain an identification ID of a target queue corresponding to the first critical section.

28. The device according to claim 27, characterized in that The transceiver module is specifically used for: The ID of the first critical section and the ID of the target queue are sent to the hardware accelerator, so that the hardware accelerator adds the ID of the first critical section to the target queue corresponding to the ID of the target queue.

29. The device according to claim 24 or 25, characterized in that The determining module is further used for: determining that a second critical section corresponds to the target queue; The transceiver module is further used to add the ID of the second critical section to the target queue; and obtain the ID of the second critical section from the target queue; The execution module is further configured to execute the second critical section according to the ID of the second critical section after completing the execution of the first critical section.

30. The device according to claim 29, characterized in that The time when the ID of the second critical section is added to the target queue is later than the time when the ID of the first critical section is added to the target queue.

Images