Nested priority lock system and implementation method

Abstract

The application provides a nested priority lock system and an implementation method, which comprises the following steps: using a litl framework, and redirecting pthread_mutex_lock to a corresponding locking function in the litl framework to implement the nested priority lock system. The nested priority lock system is applied to a NUMA architecture, and based on the thread record of the priority nested appearance, the current priority NUMA node is recorded and updated. Through the lock competitor in the priority nested environment, the application avoids the collapse of the throughput rate of the existing NUMA-aware lock in the lock nested environment, and maintains the technical effect that the throughput rate is close to that when no nesting appears.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of parallel computing, in particular, to a nested priority lock system and method. BACKGROUND

[0002] The mutex has long been the key to the scalability of multi-core systems, and has been the focus of research and optimization in the academic and industrial communities. For different computer architectures, different lock scheduling strategies are often used to improve the scalability of mutexes. With the continuous development of computer hardware, more and more heterogeneous hardware has appeared in people's life. In the traditional SMP (Symmetric Multi-Processor), all processors share the system bus, so when the number of processors increases, the competition for the system bus increases, and the system bus will become a bottleneck, so the number of CPUs in the current SMP system is generally only a few tens, and the scalability is greatly limited. NUMA (Non-Uniform Memory Access Architecture) technology effectively combines the ease of programming of SMP systems and the scalability of MPP (Massively Parallel) systems, and better solves the scalability problem of SMP systems, and has become one of the mainstream architectures of today's high-performance servers.

[0003] NUMA has multiple nodes (Node), each node can have multiple CPUs (each CPU can have multiple cores or threads), and the node uses a common memory controller, so all the memory of the node is the same for all CPUs in the node, but different for all CPUs in other nodes. Nodes can be divided into three types: local nodes (Local Node), neighbor nodes (Neighbour Node) and remote nodes (Remote Node). The speed of CPU accessing memory in different types of nodes is not the same: Local Node > Neighbour Node > Remote Node. The speed of accessing the local node is the fastest, and the speed of accessing the remote node is the slowest, that is, the access speed is related to the distance of the node, the farther the distance, the slower the access speed. In terms of mutex, the non- NUMA-aware mutex uses the first-in-first-out (FIFO) strategy to pass the mutex, which will cause a large number of remote memory accesses in the NUMA scenario, causing serious performance scalability problems. Therefore, the scalable mutex designed for NUMA systems tries to pass the mutex within a local NUMA node for as long as possible to improve performance.

[0004] NUMA-aware lock based on clh lock extension (hierarchical clh queue lock), the thread constructs the implicit local queue of the waiting thread, and only needs a cas operation to splice them into a global queue. Each thread within a NUMA node maintains a local clh queue, while there is a global queue. When a thread wants to obtain a lock, it adds itself to the local queue of the NUMA node where it is located, and the thread spins on the predecessor node of their local queue. The thread at the head of the local queue tries to splice the entire local queue onto the global queue, so that multiple threads from the same NUMA node appear consecutively in the global queue, improving memory access locality. Such an operation only needs a cas operation. hclh sacrifices the global first-in-first-out order to ensure the local lock first-in-first-out order, and the lock is preferentially passed in the local queue and provides long-term fairness.

[0005] In recent years, NUMA-aware locks also use similar strategies: HMCS uses MCS locks on multiple levels of NUMA hierarchy based on MCS locks to take advantage of the locality of each level, which is an n-element MCS lock tree. CNA lock avoids additional space occupation based on hclh: it no longer allocates a separate mutex lock for each NUMA node, but only maintains two layers of queues, and when releasing the lock, it does not put the threads of the current NUMA node into the standby queue. CNA has similar throughput in a NUMA environment as the hierarchical NUMA-aware lock, but has lower memory occupancy. Shfllock, compared with CNA, decouples the lock execution order and the lock release phase, thereby removing the traversal queue overhead on the critical path.

[0006] In summary, the existing NUMA-aware locks essentially take the approach of giving priority to threads from the same NUMA node to lock, and only guarantee long-term fairness to avoid starvation. However, the present application finds that this type of NUMA-aware lock will cause serious priority inversion in the scenario of lock nesting, resulting in the collapse of performance and throughput.

[0007] Patent document CN104834505A (application number: 201510240609.0) discloses a NUMA-aware synchronization method in a multi-core multi-thread environment, belonging to the field of parallel computing. The method proposed by the present application is: the thread inserts a synchronization request node into a linked list and spins on a local lock, and returns if the local lock is released and the request has been executed, otherwise the thread acts as a combiner thread, sets the host NUMA node, executes the requested backtracking position, and then starts executing the synchronization requests of itself and other threads, and after execution, traverses forward from the current position to find threads from the host NUMA node, if found, takes it as a new combiner thread and notifies the thread of the backtracking position, otherwise takes the next thread of the current position as a combiner thread. In the case of multi-threaded competition for access to shared resources, and the access mode of the shared resources is relatively scattered, the overhead of cross-node communication and remote memory access between multiple NUMA nodes is large. SUMMARY

[0008] In view of the defects in the prior art, the purpose of the present application is to provide a framework that can be applied in a lock nesting scenario.

[0009] According to the nested priority lock system provided by the present application, the nested priority lock system comprises:

[0010] The litl framework is adopted, and pthread_mutex_lock is redirected to the corresponding locking function in the litl framework to realize the nested priority lock system.

[0011] Preferably, the nested priority lock system is applied on a NUMA architecture, and the thread record of priority occurrence nesting is recorded and the current priority NUMA node is updated.

[0012] Preferably, when the nested priority lock system is applied in the NUMA architecture locking, the nested priority lock system directly redirects pthread_mutex_lock to the locking logic of the nested priority lock system through the weak symbol replacement method.

[0013] Preferably, the NUMA nodes comprise node 0 and node 1; the mutex A is passed in node 0; the mutex B is passed in node 1; the thread A obtains the lock A in node 0, and the thread A has priority occurrence nesting and competes for the lock B; based on the nested priority lock system, the current lock B priority is updated to be passed inside the node 0 corresponding to the thread A.

[0014] Preferably, the nested priority lock system divides all threads in the NUMA node into three priority levels of low, medium and high; the threads in the NUMA node where the current lock owner is located are set to the medium priority, and the threads in other NUMA nodes are set to the low priority; when a certain competitor appears in the nested scenario, the competitor is set to the high priority, and all threads in the node are set to the medium priority.

[0015] According to the nested priority lock system implementation method provided by the application, the litl framework is used, and pthread_mutex_lock is redirected to the corresponding locking function in the litl framework to implement the nested priority lock system.

[0016] Preferably, the nested priority lock system is applied to the NUMA architecture, and the current priority NUMA node is recorded and updated based on the thread that appears in the priority nested scenario.

[0017] Preferably, when the nested priority lock system is applied to the NUMA architecture locking, the nested priority lock system directly redirects pthread_mutex_lock to the locking logic of the nested priority lock system through the weak symbol replacement mode.

[0018] Preferably, the NUMA node includes node 0 and node 1; the mutex A is passed in node 0; the mutex B is passed in node 1; the thread A obtains the lock A in node 0, and the thread A appears in the priority nested scenario, and simultaneously competes to obtain the lock B; the current lock B priority is updated to be passed inside node 0 corresponding to the thread A based on the nested priority lock system.

[0019] Preferably, the nested priority lock system divides all threads in the NUMA node into three priority levels of low, medium and high; the threads in the NUMA node where the current lock owner is located are set to the medium priority, and the threads in other NUMA nodes are set to the low priority; when a certain competitor appears in the nested scenario, the competitor is set to the high priority, and all threads in the node are set to the medium priority.

[0020] Compared with the prior art, the application has the following beneficial effects:

[0021] 1. The application realizes the technical effect of avoiding the throughput collapse problem of the existing NUMA-aware lock in the lock nested environment and maintaining the throughput close to that when the lock nested scenario does not appear by using the lock competitor in the priority nested environment.

[0022] 2. The application realizes the technical effect of not having the throughput decline compared with the existing NUMA-aware lock when the lock nested scenario does not appear by using the efficient lock nested environment identification technology.

[0023] 3、The application realizes the technical effect of low frame memory occupation by efficient data structure design, and only 8 bytes of extra space are needed for each thread, and only 4 bytes of extra space are needed for each lock;

[0024] 4、The application only provides one set of upper framework, and the bottom local lock can be replaced by any existing lock, and only needs to be slightly modified to achieve flexible effect;

[0025] 5、The application realizes the effect of avoiding starvation by providing the same long-term fairness as NUMA-aware lock. BRIEF DESCRIPTION OF DRAWINGS

[0026] Other features, objects and advantages of the application will become more apparent from the following detailed description of non-limiting embodiments with reference to the attached drawings:

[0027] Figure 1 It is a strategy inversion example schematic diagram.

[0028] Figure 2 It is a nested priority lock framework NPLF overview schematic diagram.

[0029] Figure 3 It is a NUMA-NP lock schematic diagram.

[0030] Figure 4 It is a NUMA-NP locking and unlocking flow chart.

[0031] Figure 5 It is a NUMA-NP different path locking flow chart.

[0032] Figure 6 It is a global lock locking flow chart. DETAILED DESCRIPTION

[0033] The application will be described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be pointed out that for those skilled in the art, without departing from the concept of the application, a number of changes and improvements can be made. These all belong to the protection scope of the application.

[0034] Based on the deficiencies in the prior art, the application provides a nested priority lock system, which can avoid the strategy inversion of the originally effective priority strategy in the nested scenario, resulting in collapse of throughput, and achieve similar performance to that in the non-nested scenario. At the same time, the lock nested scenario can be applied on different bottom locks, and only simple modification is needed.

[0035] Example 1

[0036] The nested priority lock system comprises:

[0037] The nested priority lock system is implemented by using a litl framework and redirecting pthread_mutex_lock to a corresponding locking function in the litl framework.

[0038] Specifically, the nested priority lock system is applied to a NUMA architecture, and a currently priority NUMA node is recorded and updated based on a thread that appears nested first.

[0039] Specifically, when the nested priority lock system is applied to the NUMA architecture for locking, the nested priority lock system directly redirects pthread_mutex_lock to locking logic of the nested priority lock system through weak symbol replacement.

[0040] Specifically, the NUMA nodes include node 0 and node 1; mutex A is passed in node 0; mutex B is passed in node 1; thread A obtains lock A in node 0, and thread A appears nested first and competes for lock B; and current lock B is updated to be passed inside node 0 corresponding to thread A based on the nested priority lock system.

[0041] Specifically, the nested priority lock system divides all threads in the NUMA nodes into three priority levels of low, medium and high; threads in a NUMA node where a current lock owner is located are set to the medium priority, and threads in other NUMA nodes are set to the low priority; when a certain competitor appears in a nested scenario, the competitor is set to the high priority, and all threads in the node are set to the medium priority.

[0042] The nested priority lock system implementation method comprises the following steps: using a litl framework, and redirecting pthread_mutex_lock to a corresponding locking function in the litl framework to implement the nested priority lock system.

[0043] Specifically, the nested priority lock system is applied to a NUMA architecture, and a currently priority NUMA node is recorded and updated based on a thread that appears nested first.

[0044] Specifically, when the nested priority lock system is applied to the NUMA architecture for locking, the nested priority lock system directly redirects pthread_mutex_lock to locking logic of the nested priority lock system through weak symbol replacement.

[0045] Specifically, the NUMA nodes include node 0 and node 1; mutex A is passed in node 0; mutex B is passed in node 1; thread A obtains lock A in node 0, and thread A appears nested first and competes for lock B; and current lock B is updated to be passed inside node 0 corresponding to thread A based on the nested priority lock system.

[0046] Specifically, the nested priority lock system divides all threads in the NUMA node into three priority levels: low, medium, and high. Threads in the NUMA node where the current lock owner is located are set to the medium priority, and threads in other NUMA nodes are set to the low priority. When a certain competitor appears in a nested scenario, the competitor is set to the high priority, and all threads in the node are set to the medium priority.

[0047] Example 2

[0048] Embodiment 2 is a preferred embodiment of Embodiment 1

[0049] In the scenario of lock nesting, the NUMA-aware lock in the prior art has a serious policy reversal problem. As shown in Figure 1 The machine has a total of two NUMA nodes, node 0 and node 1. At this time, mutex A is passed in node 0, and mutex B is passed in node 1. Thread A gets lock A in node 0, and competes for lock B, but at this time, mutex B is being preferentially passed in node 1, and thread a cannot get lock B for a long time, and lock A also cannot be released, so that subsequent competitors in node 1 cannot execute the critical section, causing a serious problem of throughput rate reduction.

[0050] To show the severity of the problem caused by policy reversal, the present application tests on a machine with two NUMA nodes. The present application selects MCS lock as a representative of non- NUMA-aware lock. MCS lock is a widely used FIFO queue lock, which guarantees the first-in first-out order to obtain the lock, and has very strong fairness, and each thread has equal opportunity to obtain the lock. And each lock only needs one variable space, and each thread only needs to maintain a data structure with two variables. And MCS removes contention on the critical path, and the atomic operation at the tail does not affect performance most of the time. Such advantages make MCS have better scalability on non- NUMA machines, and are widely used (for example, the qspinlock in the linux kernel is an MCS queue). There are also many locks based on MCS queue in NUMA-aware locks. The present application selects HMCS lock as a representative of NUMA-aware lock. The existing NUMA-aware lock often uses global lock and local lock, and the thread needs to obtain the local lock and the global lock to enter the critical section, and HMCS is also the same. HMCS uses MCS lock on multiple levels of hierarchy to utilize the locality of each level, which is an n-element (n is the number of NUMA levels) MCS lock tree. HMCS has much better performance than other NUMA-aware locks in multi-level NUMA architecture.

[0051] The present application uses a set of more extreme scenarios to show the space that can be optimized: all threads in two NUMA nodes frequently go to get lock A and lock B, thread a in node 0 will nest to get lock A and lock B, all threads on node 0 except thread a get lock A, and threads on node 1 get lock B. Since only threads on node 1 and thread 0 get lock B, the NUMA-aware lock will make lock B preferentially pass on node 1, at this time if thread a gets lock A, it cannot get lock B and cannot release lock A, which will cause threads on node 0 to be blocked, resulting in the collapse of the throughput. Table 1 shows the problem of policy reversal in a more general case, the micro-benchmark configuration is as follows: 20 threads are created on node 0 and node 1 respectively, all threads will randomly get two different global mutexes with a probability of one half, and the threads on node 0 will nest to get lock A and lock B with a probability of 25%. In the case of lock nesting, threads in a NUMA node will nest to get the two mutexes with a given probability. The horizontal axis is the number of threads created, and the vertical axis is the throughput of the mutex. As can be seen from the figure, when extended to multiple NUMA nodes (the number of threads is greater than 20), the NUMA-aware policy of the HMCS lock fails, and its throughput drops significantly.

[0052]

[0053]

[0054] Table 1: Scalability cliff caused by policy reversal

[0055] To solve the above problems, the present application proposes a nested priority lock system, which is referred to as NPLF. As shown in Figure 2 NPLF uses the litl framework and can directly redirect pthread_mutex_lock to the corresponding locking function in NPLF. In terms of data structure, NPLF stores the context information of the lock, including the nesting level, such as thread a getting lock A will increase the nesting level by one, and when trying to get lock B, it will find that the nesting scenario occurs. Corresponding to the locking process, NPLF will decrease the nesting level by one in the unlocking process. NPLF adopts two different strategies for the no-nested scenario and the nested scenario. For the no-nested scenario, NPLF only updates the nesting level and records the outermost policy (for example, in the NUMA scenario, the outermost policy is that the current lock should preferentially pass in the internal of which NUMA node). For the nested scenario, the nesting level is updated and the current policy is aligned (for example, in the NUMA scenario, the lock should preferentially pass in the internal of the current NUMA node), and then the lock is preferentially taken through the fast path. Figure 1For example, in this scenario, thread a gets lock A and records that the outermost lock policy is to pass on node 0. When it acquires lock B, it aligns with the acquisition policy of lock A so that lock B is also passed on node 0 first. In this way, thread a can quickly acquire lock A and lock B, avoiding the phenomenon of policy inversion.

[0056] The present application applies the NPLF framework to the NUMA architecture to obtain a new policy, NUMA-NP, which can provide the ability of fast-path acquisition and the ability of alternative policies. NUMA-NP mainly passes on the thread with the highest priority first and records and updates the current priority NUMA node. Like the common NUMA-aware lock, NUMA-NP is also divided into global lock and local lock. The thread that needs to enter the critical section needs to acquire the local lock and the global lock at the same time. The waiting queue thread can inherit the global lock of the previous competitor. NUMA-NP divides the priority of the competitor into three priorities, low, medium and high, and only allows the thread to pass to the thread with the highest priority among all threads. The thread in the NUMA node where the current lock owner is located is set to medium priority, and the thread in other NUMA nodes is set to low priority. When a competitor appears in the nested scenario, it is set to high priority, and all threads in the node are set to medium priority. Figure 3 An actual example of the application of NUMA-NP is provided, as shown in Figure 3 The machine has NUMA nodes 0-3. The current priority policy is to pass on the lock in node 2 first. In the initial state, the thread in node 2 is of medium priority. At this time, a nested lock competitor appears in node 1. The priority of the competitor is adjusted to the highest. At this time, the highest priority is "high", and the global lock is acquired directly (as shown in 1). The competitor in node 2 finds that its priority is not the highest, and releases the global lock directly (as shown in 2). At the same time, the priority node of the lock is set to node 1 (to avoid unnecessary cache line migration overhead to return to node 2 quickly), so the priority of the competitor in node 1 is changed to medium priority. After the nested competitor releases the lock, the subsequent medium priority competitor in node 1 is given, avoiding the phenomenon that the nested competitor gets the first layer lock and cannot get the second layer lock for a long time.

[0057] Figure 4 The locking execution steps of NUMA-NP are described in detail. In the NUMA architecture, locking includes acquiring global lock and local lock. In the lock nesting scenario, the collapse of throughput is often because the NUMA node cannot acquire the global lock. Once the global lock is acquired, the local lock can be queued and acquired in a short time. Here, it is briefly unified as one-step locking operation.

[0058] The locking flow is shown in Figure 4 ​

[0059] Step one: add one to the nesting level;

[0060] Step two: determine whether the nesting level is greater than one, if yes, go to step five, otherwise go to step three;

[0061] Step three: record the outermost lock policy as the global policy;

[0062] Step four: enter the normal path lock, go to step seven;

[0063] Step five: fast path lock;

[0064] Step six: update the current level lock policy to align with the global policy;

[0065] Step seven: successfully get the lock and can enter the critical section.

[0066] Figure 4 The lock release process is shown:

[0067] Step one: subtract one from the nesting level;

[0068] Step two: normal path lock release;

[0069] When the application is locked, NPLF will directly redirect pthread_mutex_lock to the locking logic of NPLF through weak symbol replacement. Before locking, NPLF will first maintain the current nesting level, and then execute the fast path or normal path locking according to whether nesting occurs. Through the above form, the purpose of locking the thread that appears first in the nested case is achieved.

[0070] We show the normal path locking and fast path locking process through the flow chart. Figure 5 The specific process of each function in NUMA-NP is described in detail. The normal path process is shown in Figure 5

[0071] Step one: get the current NUMA node number;

[0072] Step two: get the local lock;

[0073] Step three: determine whether the global lock needs to be reacquired, if yes, go to step four, otherwise go to step seven

[0074] Step four: pass the counter to one

[0075] Step five: get the priority of the current global lock;

[0076] Step six: get the global lock;

[0077] Step seven: lock success;

[0078] ​Figure 5 The fast path lock acquisition procedure is shown:

[0079] Step one: set the current state as fast acquisition;

[0080] Step two: acquire the global lock with the highest priority;

[0081] For the normal path, the thread will first queue to acquire the local lock, and then determine whether the global lock needs to be acquired according to the current NUMA node and the NUMA node where the current thread holding the lock is located. If not, the lock acquisition is successful, otherwise, the priority of the thread is first determined, and then the global lock acquisition function is called according to the priority. For the fast path, the current state is only set as fast acquisition, and the global lock can be acquired with the highest priority.

[0082] The present application shows the procedure of global lock acquisition by flow chart, and the global lock in NPLF is a priority-based mutex. Figure 6 The specific procedure of global lock acquisition is described in detail.

[0083] Step one: set the mask according to the priority of the thread;

[0084] Step two: whether there is a higher priority competitor, if yes, go to step two, otherwise go to step three;

[0085] Step three: try to acquire the lock by atomic operation

[0086] Step four: whether the atomic operation is successful, if yes, go to step eleven, otherwise go to step five

[0087] Step five: update the waiter variable to block other low-priority competitors;

[0088] Step six: try to acquire the lock by atomic operation;

[0089] Step seven: whether the atomic operation is successful, if yes, go to step eleven, otherwise go to step eight;

[0090] Step eight: whether the current priority is changed, if yes, go to step nine, otherwise go to step ten;

[0091] Step nine: update the related variables, such as the current priority, the mask and the waiter variable;

[0092] Step ten: whether there is a higher priority competitor, if yes, go to step ten, otherwise go to step six;

[0093] Step eleven: the lock acquisition is successful

[0094] The global lock of the NPLF accepts the priority of the current thread through a parameter, sets a mask according to the priority, and blocks itself if there is a thread with a higher priority. Otherwise, the global lock of the NPLF blocks other threads with a lower priority according to its own priority. Meanwhile, the global lock of the NPLF also constantly updates its own priority and the current highest priority during the locking process. Once a change is found, the relevant variables are updated, and then a decision is made whether to block itself or other threads. Through this priority-based global lock, the NPLF can be nested in priority while switching the global NUMA-aware strategy in time to prevent frequent switching between different NUMA nodes caused by locking, thereby ensuring good throughput.

[0095] Example 3

[0096] Embodiment 3 is a preferred embodiment of Embodiment 1 and / or Embodiment 2

[0097] The present application utilizes existing NUMA-aware locks in combination with the proposed NPLF framework. Based on the existing multi-level NUMA-aware lock, the present application avoids policy inversion in the nested scenario, and aligns the lock policy to preferentially pass to other competitors of the current node. In terms of memory occupation, the NPLF does not need to occupy excessive additional space.

[0098] The present application is tested on an arm machine with a more complex NUMA architecture, the processor model is Huawei Kunpeng 920, the number of NUMA nodes is 4, each NUMA node has 24 hardware threads, and the linux kernel version is 5.10.0. The present application compares the NPLF with the existing most advanced NUMA-aware lock CNA, HMCS and the most popular MCS lock. The present application adopts two groups of controls, the first group is the no nesting scenario (No Nest), which shows that the NPLF does not bring any obvious overhead, and the second group is the nested scenario (Nested), which proves the effect brought by the NPLF.

[0099] As shown in Table 2, due to the complex NUMA architecture on the arm machine, the throughput of HMCS is much higher than that of CNA, so the NPLF of the present application is implemented based on HMCS. It can be found that compared with HMCS, the NPLF does not have any decrease in throughput when there is no nesting, and when the nested scenario occurs, the NPLF brings a performance improvement of 90%; the test results are shown in Table 2.

[0100] MCS HMCS NPLF CNA NONEST 1.92E+06 4.43E+06 4.47E+06 2.25E+06 NEST 838987 1.98E+06 3.67E+06 1.43E+06

[0101] Table 2 test results

[0102] Those skilled in the art know that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the same program can also be implemented in the form of logic gate, switch, special integrated circuit, programmable logic controller and embedded microcontroller, etc. by logically programming the method steps. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures in the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing methods and structures in the hardware component.

[0103] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily without conflict.

Claims

1. A nested priority lock system, characterized in that: include: Use litl framework and redirect pthread_mutex_lock to the corresponding lock function in litl framework to implement nested priority lock system; Apply the nested priority lock system to the NUMA architecture, record and update the current priority NUMA node based on the thread where the nesting occurs first; When the nested priority lock system is applied to NUMA architecture locking, the nested priority lock system directly redirects pthread_mutex_lock to the locking logic of the nested priority lock system through weak symbol replacement; NUMA nodes include node 0 and node 1; mutex A is transferred within node 0; mutex B is transferred within node 1; Thread A obtains lock A in node 0, and thread A is nested first, competing for lock B at the same time; based on the nested priority lock system, the current lock B is updated and passed preferentially within node 0 corresponding to thread A.

2. The nested priority locking system according to claim 1, characterized in that: The nested priority lock system divides all threads in a NUMA node into three priorities: low, medium, and high. The threads in the NUMA node where the current lock owner is located are set to medium priority, and the threads in other NUMA nodes are set to low priority. When a competitor encounters a nested scenario, it will set itself to high priority and all threads in this node to medium priority.

3. A nested priority lock system implementation method, characterized in that: include: Use litl framework and redirect pthread_mutex_lock to the corresponding lock function in litl framework to implement nested priority lock system; Apply the nested priority lock system to the NUMA architecture, record and update the current priority NUMA node based on the thread where the nesting occurs first; When the nested priority lock system is applied to NUMA architecture locking, the nested priority lock system directly redirects pthread_mutex_lock to the locking logic of the nested priority lock system through weak symbol replacement; NUMA nodes include node 0 and node 1; mutex A is transferred within node 0; mutex B is transferred within node 1; Thread A obtains lock A in node 0, and thread A is nested first, competing for lock B at the same time; based on the nested priority lock system, the current lock B is updated and passed preferentially within node 0 corresponding to thread A.

4. The nested priority lock system implementation method according to claim 3, characterized in that: The nested priority lock system divides all threads in a NUMA node into three priorities: low, medium, and high. The threads in the NUMA node where the current lock owner is located are set to medium priority, and the threads in other NUMA nodes are set to low priority. When a competitor encounters a nested scenario, it will set itself to high priority and all threads in this node to medium priority.

Images