Nesting priority lock system and implementation method

Abstract

The invention provides a nested priority lock system and an implementation method thereof, and the implementation method comprises the following steps: adopting a litl frame, and redirecting pthread mutexlock to a corresponding locking function in the litl frame, so as to implement the nested priority lock system. 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 where nesting occurs preferentially. According to the invention, by preferentially nesting the lock competitors in the environment, the problem of throughput rate collapse of the existing NUMA sensing lock in the lock nesting environment is avoided, and the technical effect that the throughput rate is close to that when nesting does not occur is maintained.

Description

Technical Field

[0001] The present invention relates to the field of parallel computing technology, and in particular to a nested priority lock system and method. Background Art

[0002] Mutex locks have long been the key to the scalability of multi-core systems, and are also a hot topic for research and optimization in academia and industry. Different lock scheduling strategies are often used for different computer architectures to improve the scalability of mutex locks. With the continuous development of computer hardware, more and more heterogeneous hardware has appeared around us. In traditional SMP (symmetric multiprocessors), all processors share the system bus. Therefore, when the number of processors increases, the competition conflict of the system bus increases, and the system bus will become a bottleneck. Therefore, the number of CPUs in SMP systems is generally only dozens, and the scalability is greatly limited. NUMA (Non-Uniform Memory Access Architecture) technology effectively combines the characteristics of easy programmability of SMP systems and easy scalability of MPP (Massive Parallelism) systems, and better solves the scalability problem of SMP systems. It has become one of the mainstream architectures of today's high-performance servers.

[0003] NUMA has multiple nodes, each of which can have multiple CPUs (each CPU can have multiple cores or threads). A shared memory controller is used within the node, so all the memory of the node is equivalent for all CPUs in the node, but different for all CPUs in other nodes. Nodes can be divided into three types: local nodes, neighbor nodes, and remote nodes. The speed at which the CPU accesses the memory of different types of nodes is different: local nodes > neighbor nodes > remote nodes. 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 between the nodes. The farther the distance, the slower the access speed. In terms of mutexes, non-NUMA-aware mutexes use a first-in, first-out (FIFO) strategy to pass mutexes, which will cause a large number of remote memory accesses in NUMA scenarios, causing serious performance scalability issues. Therefore, the scalable mutexes designed for NUMA systems allow as many mutexes as possible to be passed in the local NUMA node within a period of time to improve performance.

[0004] Let's take the hclh lock as an example. Based on the NUMA-aware lock (hierarchical clh queue lock) extended by the clh lock, threads build implicit local queues of waiting threads, and only one cas operation is needed to splice them into a global queue. Threads in each NUMA node maintain local clh queues and a global queue. When a thread wants to acquire a lock, it adds itself to the local queue of the NUMA node where it is located, and threads spin on the predecessor node of their local queues. The thread at the head of the local queue attempts to splice the entire local queue into the global queue so that multiple threads from the same NUMA node appear continuously in the global queue, improving memory access locality. Such an operation only requires one cas operation. hclh sacrifices the global first-in-first-out order to ensure the first-in-first-out order of local locks. Locks are passed in the local queue first and provide long-term fairness.

[0005] The NUMA-aware locks studied in recent years also adopt a similar strategy: HMCS uses MCS locks on multiple levels of NUMA hierarchies based on MCS locks to exploit the locality of each level. It is an n-element MCS lock tree. CNA locks avoid extra space occupation based on hclh: it no longer allocates a separate mutex lock for each NUMA node, only maintains two layers of queues, and puts threads that are not in the current NUMA node into the backup queue when releasing the lock. CNA has a similar throughput to hierarchical NUMA-aware locks in a NUMA environment, but has lower memory usage. Compared with CNA, Shfllock decouples the lock execution order and the lock release phase, thereby removing the overhead of traversing the queue on the critical path.

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

[0007] Patent document CN104834505A (application number: 201510240609.0) discloses a NUMA-aware synchronization method in a multi-core multi-threaded environment, belonging to the field of parallel computing. The method proposed by the present invention is: a thread inserts a synchronization request node into a linked list and spins on a local lock, 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 backtracking position of the request, and then starts to execute the synchronization request of itself and other threads, and after the execution is completed, traverses forward from the current position to find a thread from the host NUMA node, if found, it is used as a new combiner thread and notifies the thread of the backtracking position, otherwise the next thread at the current position is used as a combiner thread. In the case where multiple threads compete to access shared resources and the shared resource access mode is relatively scattered, the overhead of cross-node communication and remote memory access between multiple NUMA nodes is large. Summary of the invention

[0008] In view of the defects in the prior art, an object of the present invention is to provide a framework that can be applied to lock nesting scenarios.

[0009] A nested priority lock system provided according to the present invention comprises:

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

[0011] Preferably, the nested priority lock system is applied to the NUMA architecture, and the currently prioritized NUMA node is recorded and updated based on the threads where the nesting occurs first.

[0012] Preferably, 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 by means of weak symbol replacement.

[0013] Preferably, the 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 within node 0, and thread A is nested first, and competes to obtain lock B at the same time; based on the nested priority lock system update, the current lock B is preferentially transferred within node 0 corresponding to thread A.

[0014] Preferably, the nested priority lock system divides all threads in the 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 appears in a nested scenario, it will set itself to high priority and set all threads of this node to medium priority.

[0015] A nested priority lock system implementation method provided by the present invention includes: adopting a litl framework and redirecting pthread_mutex_lock to a corresponding locking function in the litl framework to implement a nested priority lock system.

[0016] Preferably, the nested priority lock system is applied to the NUMA architecture, and the currently prioritized NUMA node is recorded and updated based on the threads where the nesting occurs first.

[0017] Preferably, 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 by means of weak symbol replacement.

[0018] Preferably, the 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 within node 0, and thread A is nested first, and competes to obtain lock B at the same time; based on the nested priority lock system update, the current lock B is preferentially transferred within node 0 corresponding to thread A.

[0019] Preferably, the nested priority lock system divides all threads in the 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 appears in a nested scenario, it will set itself to high priority and set all threads of this node to medium priority.

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

[0021] 1. The present invention achieves the technical effect of avoiding the throughput collapse problem of the existing NUMA-aware lock in a lock nesting environment by giving priority to the lock competitors in the lock nesting environment, and maintaining the throughput close to that when no nesting occurs;

[0022] 2. The present invention uses a highly efficient technology for identifying nested environments to achieve a technical effect of no decrease in throughput compared to existing NUMA-aware locks when no lock nesting scenario occurs;

[0023] 3. The present invention achieves the technical effect of low framework memory usage through efficient data structure design, requiring only 8 bytes of additional space per thread and only 4 bytes of additional space per lock;

[0024] 4. The present invention only provides a set of upper framework, and the local lock of the bottom layer can be replaced with any existing lock, and only slightly modified to achieve flexible and changeable effects;

[0025] 5. The present invention achieves the effect of avoiding starvation by providing the same long-term fairness as NUMA-aware locks. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0027] Figure 1 This is a schematic diagram of an example of a strategy reversal.

[0028] Figure 2 The figure is a schematic diagram of the nested priority lock framework NPLF.

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

[0030] Figure 4 Flowchart of locking and releasing for NUMA-NP.

[0031] Figure 5 Flowchart for locking different paths for NUMA-NP.

[0032] Figure 6 Locking flowchart for the global lock. DETAILED DESCRIPTION

[0033] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0034] Based on the deficiencies in the prior art, the present invention provides a nested priority lock system, which can avoid the policy reversal of the original well-performing priority strategy in the nested scenario, resulting in a throughput crash, and achieve a performance similar to that of the non-nested scenario. At the same time, the lock nesting scenario can be applied to different underlying locks with only simple modifications.

[0035] Example 1

[0036] A nested priority lock system provided according to the present invention comprises:

[0037] The litl framework is used, and pthread_mutex_lock is redirected to the corresponding locking function in the litl framework to implement a nested priority lock system.

[0038] Specifically, the nested priority lock system is applied to the NUMA architecture, and the currently prioritized NUMA node is recorded and updated based on the threads where the nesting occurs first.

[0039] Specifically, 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 by means of weak symbol replacement.

[0040] Specifically, 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 within node 0, and thread A is nested first, and competes to obtain lock B at the same time; based on the nested priority lock system update, the current lock B is preferentially transferred within node 0 corresponding to thread A.

[0041] Specifically, the nested priority lock system divides all threads in the 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 appears in a nested scenario, it will set itself to high priority and set all threads of this node to medium priority.

[0042] A nested priority lock system implementation method provided by the present invention includes: adopting a litl framework and redirecting pthread_mutex_lock to a corresponding locking function in the litl framework to implement a nested priority lock system.

[0043] Specifically, the nested priority lock system is applied to the NUMA architecture, and the currently prioritized NUMA node is recorded and updated based on the threads where the nesting occurs first.

[0044] Specifically, 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 by means of weak symbol replacement.

[0045] Specifically, 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 within node 0, and thread A is nested first, and competes to obtain lock B at the same time; based on the nested priority lock system update, the current lock B is preferentially transferred within node 0 corresponding to thread A.

[0046] Specifically, the nested priority lock system divides all threads in the 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 appears in a nested scenario, it will set itself to high priority and set all threads of this node to 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 locks in the prior art will have serious policy inversion problems. Figure 1 As shown in the figure, the machine has two NUMA nodes in total - node 0 and node 1. At this time, mutex A is transferred in node 0, and mutex B is transferred in node 1. Thread A obtains lock A in node 0 and competes for lock B at the same time. However, mutex B is being transferred preferentially in node 1 at this time. At this time, thread A cannot obtain lock B for a long time, and lock A will not be released. Subsequent competitors in node 1 are also unable to execute critical sections, resulting in a serious problem of reduced throughput.

[0050] In order to demonstrate the seriousness of the problem caused by policy inversion, the present invention was tested on a machine with two NUMA nodes. The present invention selected the MCS lock as the representative of non-NUMA-aware locks. The MCS lock is a widely used FIFO queue lock, which guarantees the lock to be obtained in the first-in-first-out order. It is very fair and each thread has an equal opportunity to obtain the lock. Moreover, each lock only requires space for one variable, and each thread only needs to maintain a data structure with two variables. In addition, MCS removes contention on the critical path, and the atomic operation at the end of the queue does not affect performance most of the time. Such advantages make MCS have better scalability on non-NUMA machines and widely used (for example, the qspinlock in the Linux kernel is the MCS queue). There are also many locks based on the MCS queue in NUMA-aware locks. The present invention selects the HMCS lock as the representative of NUMA-aware locks. Existing NUMA-aware locks often use global locks and local locks. A thread needs to acquire both the local lock and the global lock to enter the critical section. The same is true for HMCS. HMCS uses MCS locks on a multi-level hierarchy to utilize the locality of each level. It is an n-element (n is the number of NUMA levels) MCS lock tree. HMCS performs much better than other NUMA-aware locks in a multi-level NUMA architecture.

[0051] The present invention uses a relatively extreme scenario to demonstrate the space that can be optimized: all threads in two NUMA nodes frequently acquire locks A and B, thread a in node 0 will nestedly acquire locks A and B, all threads on node 0 except thread a acquire lock A, and threads on node 1 acquire lock B. Since only threads on node 1 and thread 0 acquire lock B, NUMA-aware locks will make lock B preferentially transmitted on node 1. At this time, if thread a acquires lock A, it will be blocked because it cannot acquire lock B and cannot release lock A, resulting in a collapse of throughput. Table 1 shows the problem of policy reversal in a more general case. The micro-benchmark test configuration is as follows: 20 threads are created on node 0 and node 1 respectively, and all threads will randomly acquire two different global mutex locks with a probability of half each, and threads on node 0 will nestedly acquire locks A and B with a probability of 25%. In the case of lock nesting, threads in a certain NUMA node will nestedly acquire these two mutex locks with a given probability. The horizontal axis is the number of threads created, and the vertical axis is the throughput of the mutex lock. As can be seen from the figure, when expanded to multiple NUMA nodes (the number of threads is greater than 20), the NUMA awareness strategy of the HMCS lock fails and its throughput drops significantly.

[0052]

[0053]

[0054] Table 1 Scalability cliff caused by strategy reversal

[0055] In order to solve the above problems, the present invention proposes a nested priority lock system, which is referred to as NPLF. Figure 2 As shown, NPLF uses the litl framework, which 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 - for example, after thread a obtains lock A, the nesting level will be increased by one. When trying to obtain lock B, it will be found that a nested scenario has occurred. Corresponding to the locking process, NPLF will reduce the nesting level by one in the lock release process. NPLF adopts two different strategies for non-nested scenarios and nested scenarios. For non-nested scenarios, NPLF will only update the nesting level and record the outermost strategy (taking the NUMA scenario as an example, the outermost strategy is which NUMA node the current lock is preferentially passed within). For nested scenarios, the nesting level will be updated and the current layer strategy will be aligned (taking the NUMA scenario as an example, the lock should be preferentially passed within the current NUMA node), and then the lock will be preferentially obtained through the fast path. Figure 1For example, in this scenario, after thread a obtains lock A, it will record that the outermost lock strategy is transmitted on node 0. When nested acquisition of lock B is performed, it will be aligned with the acquisition strategy of lock A so that lock B is also preferentially transmitted in node 0. In this way, thread a can quickly obtain locks A and B, avoiding the phenomenon of strategy reversal.

[0056] The present invention applies the NPLF framework to the NUMA architecture and obtains a new strategy NUMA-NP, which can provide the ability of fast path acquisition and the ability of providing replaceable strategies. NUMA-NP mainly prioritizes nested threads, and records and updates the current priority NUMA node. Similar to the usual NUMA-aware lock, NUMA-NP is also divided into global locks and local locks. Threads that need to enter the critical section need to acquire local locks and global locks at the same time, and threads waiting in the queue can inherit the global lock of the previous competitor. NUMA-NP divides the priority of competitors into three priorities: low, medium, and high, and only allows threads to be passed to the thread with the highest priority among all current threads. 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 appears in a nested scenario, it will set itself to high priority, and set all threads of this node to medium priority. Figure 3 Provides practical examples of NUMA-NP applications, such as Figure 3 As shown, there are NUMA nodes 0-3 on the machine, and the current priority strategy is that the lock is given priority. When the initial state is passed inside node 2, the thread in node 2 is of medium priority. At this time, a competitor for a nested lock appears in node 1, and the priority of the competitor is adjusted to the highest. At this time, the highest priority is "high", and it directly obtains the global lock (as shown in 1 in the figure). The competitor in node 2 finds that its priority is not the highest, so it directly releases the global lock (as shown in 2 in the figure), and sets the priority node of the lock to node 1 (to avoid quickly returning to node 2 and generating unnecessary cache line migration overhead). Therefore, the priority of the competitor in node 1 becomes medium priority, and then the nested competitor releases the lock and hands it over to the subsequent medium priority competitor in node 1, avoiding the phenomenon that the nested competitor gets the first layer of lock but cannot get the nested second layer of lock for a long time.

[0057] Figure 4 This chapter describes the locking execution steps of NUMA-NP in detail. In the NUMA architecture, locking includes adding global locks and adding local locks. In the scenario of nested locks, the throughput crash is often caused by the NUMA node not being able to obtain the global lock. Once the global lock is obtained, the local lock can be queued for acquisition in a short time. Here, it is briefly unified into a one-step locking operation.

[0058] The locking process is as follows Figure 4 As shown:

[0059] Step 1: Add one nesting layer;

[0060] Step 2: Determine whether the number of nesting levels is greater than one, if yes, go to step 5, otherwise go to step 3;

[0061] Step 3: Record the outermost lock strategy as the global strategy;

[0062] Step 4: Enter the normal path to lock, and go to step 7;

[0063] Step 5: Fast path locking;

[0064] Step 6: Update the current level lock strategy to align with the global strategy;

[0065] Step 7: After successfully getting the lock, you can enter the critical area.

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

[0067] Step 1: Reduce the number of nesting levels by one;

[0068] Step 2: Release the lock in the normal path;

[0069] When the application is locking, NPLF will directly redirect pthread_mutex_lock to NPLF's locking logic by weak symbol replacement. Before locking, NPLF will first maintain the current nesting level, and then execute fast path or normal path locking according to whether nesting occurs. Through the above form, the purpose of locking threads with nesting is achieved first.

[0070] We use a flowchart to show the normal path locking and fast path locking processes. Figure 5 The specific process of each function in NUMA-NP is described in detail. The normal path process is as follows Figure 5 As shown:

[0071] Step 1: Get the current NUMA node number;

[0072] Step 2: Get the local lock;

[0073] Step 3: Determine whether you need to reacquire the global lock. If yes, go to step 4. Otherwise, go to step 7.

[0074] Step 4: Set the transfer counter to 1

[0075] Step 5: Get the priority of the current global lock acquisition;

[0076] Step 6: Get the global lock;

[0077] Step 7: Locking is successful;

[0078] Figure 5 The fast path locking process is shown:

[0079] Step 1: Set the current state to quick acquisition;

[0080] Step 2: Acquire the global lock with the highest priority;

[0081] For the normal path, the thread will first queue up to acquire the local lock, and then determine whether it needs to acquire the global lock based on the current NUMA node and the NUMA node where the current lock-holding thread is located. If not, the lock is acquired successfully, otherwise it will first determine its own priority, and then call the global lock acquisition function based on its own priority. For the fast path, you only need to set the current state to fast acquisition to acquire the global lock with the highest priority.

[0082] The present invention uses a flow chart to show the process of acquiring a global lock. In NPLF, the global lock is a priority-based mutual exclusion lock. Figure 6 The specific process of global lock acquisition is described in detail.

[0083] Step 1: Set the mask according to its own priority;

[0084] Step 2: Check if there is a competitor with a higher priority. If yes, go to step 2; otherwise, go to step 3.

[0085] Step 3: Try atomic operation to acquire lock

[0086] Step 4: Check whether the atomic operation is successful. If yes, go to step 11. Otherwise, go to step 5.

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

[0088] Step 6: Try to lock the atomic operation;

[0089] Step 7: Check whether the atomic operation is successful. If yes, go to step 11; otherwise, go to step 8.

[0090] Step 8: Check whether the current priority has changed. If yes, go to step 9; otherwise, go to step 10.

[0091] Step 9: Update related variables, such as current priority, mask, and waiter variables;

[0092] Step 10: Is there a competitor with a higher priority? If yes, go to step 10; otherwise, go to step 6;

[0093] Step 11: Lock successfully

[0094] NPLF's global lock accepts the priority of the current thread through parameters, sets a mask based on this priority, and blocks itself if there is a thread with a higher priority. Otherwise, it will block other low-priority threads according to its own priority. At the same time, it will constantly update its own priority and the current highest priority during the locking process. Once a change is found, it will update the relevant variables and then make a decision whether to block itself or other threads. Through this priority-based global lock, NPLF can switch the global NUMA awareness policy in time while giving priority to nesting, preventing locks from frequently switching between different NUMA nodes, thereby ensuring good throughput.

[0095] Example 3

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

[0097] The present invention utilizes the existing NUMA-aware locks and combines them with the proposed NPLF framework. Based on the existing multi-level NUMA-aware locks, the present invention avoids the policy inversion in the nested scenario, and it aligns the lock policy to other competitors of the current node first. In terms of memory usage, NPLF does not need to occupy too much extra space.

[0098] The present invention is tested on an arm machine with a more complex NUMA architecture, with a processor model of Huawei Kunpeng 920, 4 NUMA nodes, 24 hardware threads per NUMA node, and a Linux kernel version of 5.10.0. The present invention compares NPLF with the most advanced existing NUMA-aware locks CNA, HMCS, and the most popular MCS lock. The present invention uses two groups of controls, the first group is a no nested scenario (No Nest), to show that NPLF does not bring any obvious overhead, and the second group is a nested scenario (Nested), to prove the effect of NPLF.

[0099] As shown in Table 2, due to the complex NUMA architecture on the arm machine, the throughput of HMCS is much better than that of CNA. Therefore, the NPLF of the present invention is implemented based on HMCS. It can be found that compared with HMCS, there is no decrease in the throughput of NPLF when there is no nesting, and when there is a nesting scenario, NPLF brings a 90% performance improvement; 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 its various modules provided by the present invention in a purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and its various modules provided by the present invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing the method and structures within the hardware component.

[0103] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A nested priority lock system, characterized in that: include: The litl framework is used, and pthread_mutex_lock is redirected to the corresponding locking function in the litl framework to implement a nested priority lock system.

2. The nested priority locking system according to claim 1, characterized in that: The nested priority lock system is applied to the NUMA architecture, and the current priority NUMA node is recorded and updated based on the priority of the nested threads.

3. The nested priority locking system according to claim 2, characterized in that: 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.

4. The nested priority locking system according to claim 3, characterized in that: NUMA nodes include node 0 and node 1; mutex A is transferred in node 0; mutex B is transferred in 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 inside node 0 corresponding to thread A.

5. The nested priority locking system according to claim 4, 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 set all threads in this node to medium priority.

6. A method for implementing a nested priority lock system, characterized in that: include: The litl framework is used, and pthread_mutex_lock is redirected to the corresponding locking function in the litl framework to implement a nested priority lock system.

7. The nested priority lock system implementation method according to claim 6, characterized in that: The nested priority lock system is applied to the NUMA architecture, and the current priority NUMA node is recorded and updated based on the priority of the nested threads.

8. The nested priority lock system implementation method according to claim 7, characterized in that: 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.

9. The nested priority lock system implementation method according to claim 8, characterized in that: NUMA nodes include node 0 and node 1; mutex A is transferred in node 0; mutex B is transferred in 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 inside node 0 corresponding to thread A.

10. The nested priority lock system implementation method according to claim 9, 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 set all threads in this node to medium priority.

Images