Lock-resource transferring method and apparatus, and computer device

Abstract

A lock-resource transferring method and apparatus, and a computer device, which are applied to the technical field of computers. The method comprises: acquiring n actual running latencies and n target latency requirements of n target threads that contend for the same mutual exclusion lock, wherein the n target threads at least run on two NUMA nodes; determining n disorder requirements of the n target threads, wherein each disorder requirement is used for representing the degree of urgency of a target thread needing to hold the mutual exclusion lock; and finally, on the basis of the n disorder requirements, determining the disorder degree of the mutual exclusion lock, such that the mutual exclusion lock is transferred on the basis of the disorder degree, wherein the disorder degree is used for representing the threshold value for the number of times the mutual exclusion lock is transferred each time same is held, and the threads running on the same NUMA node are adjacently arranged on a lock transfer path. In the method, during the running of threads, disorder requirements of all competitors are mapped, as required, to the global disorder degree of a related NUMA sensing lock, such that the disorder degree of the NUMA sensing lock can be adjusted on the basis of the disorder requirements of different threads, so as to meet the latency requirements of all competitors.

Description

Method, device and computer equipment for transferring lock resources

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 29, 2024, with application number 202410234644.0 and application name “A method, device and computer equipment for transmitting lock resources”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a method and apparatus for transferring lock resources and a computer device. Background Art

[0003] Mutual exclusion locks are a widely used synchronization primitive that provide mutually exclusive access guarantees for multi-threaded applications. When multiple threads need to modify shared data (such as the same database entry), they compete to acquire the mutex lock. Only the thread that has acquired the mutex lock can modify the shared data at any given time. If a mutex lock is acquired by one thread, the other competing threads are forced to sleep.

[0004] The performance scalability of mutex locks is a key factor in determining application performance. To improve the scalability of mutex locks on different hardware, academia and industry have proposed a series of techniques, including: alleviating contention for a single cache line by splitting contention, aggregating mutex lock competitors on the same non-uniform memory access (NUMA) node for execution, and batching the critical sections of lock competitors local to NUMA nodes to avoid excessive cross-NUMA node cache consistency overhead.

[0005] However, existing NUMA-aware locks (including global mutexes and local mutexes on each NUMA node) cannot guarantee tail latency. This is because the out-of-order degree of NUMA-aware locks is defined per lock (globally), affecting the lock acquisition latency of all threads. Different threads have different latency requirements and therefore different out-of-order requirements (privately). Therefore, the out-of-order degree of NUMA-aware locks is difficult to control based on the out-of-order requirements of different threads, resulting in a significant semantic gap.

[0006] Summary of the Invention

[0007] The present application provides a lock resource transfer method, apparatus, and computer device for mapping the out-of-order requirements of all competitors (i.e., the n out-of-order requirements of n target threads) to the global out-of-order degree of the relevant NUMA-aware lock (i.e., the out-of-order degree of the global mutex lock) as needed when the threads are running, so that the out-of-order degree of the NUMA-aware lock can be adjusted according to the out-of-order requirements of different threads to meet the latency requirements of all competitors.

[0008] Based on this, the embodiments of the present application provide the following technical solutions:

[0009] In a first aspect, the present application provides a method for transferring lock resources. The method specifically includes the following steps: First, a device obtains n actual runtime latencies and n target latency requirements of n target threads, where each target thread corresponds to one actual runtime latency and one target latency requirement. The n target threads are threads currently competing for the same global mutex lock, and these n target threads run on at least two NUMA nodes, where n ≥ 2. The device then further determines n out-of-order requirements for the n target threads based on the obtained n actual runtime latencies and n target latency requirements, where each target thread corresponds to one out-of-order requirement, and the out-of-order requirement is used to indicate the urgency with which the target threads need to hold the global mutex lock. Finally, the device determines the disorder degree of the global mutex lock based on the n disorder requirements obtained, so that the global mutex lock is transferred based on the disorder degree, wherein the disorder degree is used to characterize the threshold of the number of transfers each time the global mutex lock is held. In addition, it should be noted that threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path, so that the critical sections of the NUMA local lock competitors can be batched, which can effectively avoid the frequent cache consistency overhead across NUMA nodes.

[0010] In the above-mentioned embodiment of the present application, when the threads are running, the out-of-order requirements of all competitors (i.e., the n out-of-order requirements of n target threads) are mapped on demand to the global out-of-order degree of the relevant NUMA-aware lock (i.e., the out-of-order degree of the global mutex lock), so that the out-of-order degree of the NUMA-aware lock can be adjusted according to the out-of-order requirements of different threads to meet the latency requirements of all competitors.

[0011] In a possible implementation of the first aspect, an implementation method for determining the disorder degree of the global mutex lock based on n disorder requirements may be: the device updates the disorder degree of the global mutex lock in real time during the transfer process of the global mutex lock based on the disorder requirement of the target thread on the lock transfer path, so that the global mutex lock is transferred based on the real-time updated disorder degree.

[0012] In the above-mentioned embodiment of the present application, the device dynamically updates the disorder degree of the global mutex lock during the global mutex lock transfer process, in order to avoid causing additional overhead on the critical path.

[0013] In a possible implementation of the first aspect, the method may further include: when the disorder degree exceeds a preset time period and is not updated, increasing the value of the disorder degree according to a target preset gradient. For example, when it is found that the upper limit of the number of lock transfers required by the current competitor is smaller (that is, the latency requirement is tighter), the transfer number threshold of the current global mutex lock is updated, otherwise the transfer number threshold remains unchanged. In addition, in order to cope with the target thread with the tightest latency requirement, the value of the transfer number threshold of the global mutex lock can increase over time, or, when the tightest target thread no longer acquires the global mutex lock, the transfer number threshold of the global mutex lock can also slowly increase until the next on-demand update.

[0014] In the above-mentioned embodiment of the present application, when the disorder degree is not updated for a long time, it means that the disorder degree of the global mutex lock is too tight. The disorder degree can be relatively reduced to improve the throughput while ensuring the latency.

[0015] In a possible implementation manner of the first aspect, the out-of-order requirement may be characterized by an upper limit on the number of transfers required by the target thread each time the global mutex lock is held.

[0016] In the above implementation of this application, the target threads have different requirements for the degree of out-of-order locks on the global mutex due to latency requirements, contention levels, and other factors. To meet their respective latency requirements, these threads each expect the maximum number of transfers per global mutex lock to be the out-of-order lock requirement of each target thread. This provides flexibility.

[0017] In one possible implementation of the first aspect, a first thread is one of n target threads, and the first thread includes m first code snippets with latency requirements, where m ≥ 1. One implementation of obtaining the n actual runtime delays and n target latency requirements of the n target threads may include: selecting a target thread from the n target threads as the first thread, assuming that the first thread includes m (m ≥ 1) code snippets with latency requirements, and the code snippet may be referred to as the first code snippet. At the current moment, obtaining the first actual runtime delay and first target latency requirement of the first code snippet currently being executed by the first thread; then, using each of the n target threads as the first thread, repeating the above steps until obtaining the n first actual runtime delays and n first target latency requirements of the n first code snippets currently being executed by each of the n target threads.

[0018] In the above-mentioned embodiment of the present application, what is obtained is the actual runtime delay and corresponding delay requirement of the code fragment with delay requirement being executed by each target thread at a specific moment. Therefore, the out-of-order requirement of each target thread is also the current moment. The out-of-order requirement will take different values ​​due to the different code fragments with delay requirements being executed at the current moment, which in turn affects the degree of out-of-order of the subsequent global mutex lock. Therefore, the degree of out-of-order of the global mutex lock is dynamic, real-time, and updated on demand, and is practical.

[0019] In a possible implementation of the first aspect, before obtaining n actual running delays and n target delay requirements of n target threads, the method may further include: determining n target threads from p threads, where the p threads are threads competing for the same global mutex lock at the current moment, and p ≥ n.

[0020] In the above embodiment of the present application, n target threads can be determined from p (p≥n) threads, and the remaining pn threads are out-of-order waiters, waiting to join the competition queue later to compete for the above-mentioned global mutex lock. Through purposeful screening, the throughput is improved while ensuring the latency requirements.

[0021] In a possible implementation of the first aspect, a first implementation method for determining the n target threads from p threads may be: the device determines n target threads based on p computing powers, wherein the p computing powers are the computing powers of the p cores running the p threads, one core runs one thread at the current moment, the n target computing powers are all greater than pn computing powers, the n target computing powers are the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers are the computing powers of the pn cores among the p cores excluding the n target cores.

[0022] In the above-mentioned embodiment of the present application, only n target threads whose computing power reaches the threshold can join the competitor queue, and the remaining pn threads become out-of-order waiters. By dynamically prioritizing suitable competitors according to the competitor attributes and the competition situation of the mutex lock at runtime, the throughput is maximized.

[0023] In one possible implementation of the first aspect, the computing power of each core can be reflected by an assigned score value, and the computing power and the score value are positively correlated. For example, the aforementioned p computing powers can be reflected by the p assigned score values ​​(i.e., they are scored based on their ability to execute critical sections). Then, one implementation method for determining n target threads based on the p computing powers can be: first, determine n target score values ​​greater than a score threshold from the p score values, and then determine the n threads corresponding to the n target score values ​​as the n target threads. In other words, the threads whose score values ​​are greater than the preset score threshold are determined as the target threads.

[0024] In the above-mentioned embodiment of the present application, since the computing power of the core is not easy to quantify, the computing power of the core is reflected by a fractional value, which makes the implementation method simpler.

[0025] In a possible implementation of the first aspect, the method may further include: when the degree of contention for the global mutex does not meet a preset condition, lowering the score threshold according to a preset gradient (which may be referred to as a first preset gradient), wherein the preset condition is used to reflect whether the global mutex is sufficiently contentious.

[0026] In the above-mentioned embodiment of the present application, if the competition is insufficient, the score threshold is lowered so that more threads running on cores with lower computing power can also join the competition queue to improve the throughput.

[0027] In a possible implementation of the first aspect, the method may further include: when the degree of competition for the global mutex lock reaches a preset condition, increasing the score threshold according to a preset gradient (which may be referred to as a second preset gradient), wherein the preset condition is used to reflect whether the global mutex lock is sufficiently competitive.

[0028] In the above-mentioned embodiment of the present application, if the competition is sufficient, the score threshold is increased so that only threads running on cores with higher computing power can join the competition queue to improve the throughput.

[0029] In a possible implementation of the first aspect, the computing power of the core is related to the core type of the core; the larger the core, the greater the computing power.

[0030] In the above-mentioned embodiments of the present application, the core type of the core can be reflected by the computing power.

[0031] In a possible implementation of the first aspect, the p cores include at least two core types.

[0032] In the above implementation of the present application, since the present application is a dynamic out-of-order priority, there must be at least two core types for this solution to be meaningful.

[0033] In a possible implementation manner of the first aspect, the core type includes at least: a large core, a medium core, or a small core.

[0034] In the above embodiments of the present application, several typical core types are specifically described, which have wide applicability.

[0035] In a possible implementation of the first aspect, the p threads form a waiting queue, and n target threads are determined from the p threads. Another implementation may be: n target threads are determined from the p threads based on a first-in first-out (FIFO) principle.

[0036] In the above embodiment of the present application, the competing queues competing for the same global mutex lock are selected from p threads based on the FIFO principle. This single-queue lock will immediately enter the Linux kernel, saving time.

[0037] The second aspect of the present application also provides a method for transferring lock resources, which specifically includes: first, the device will obtain p actual runtime delays and p target latency requirements of p threads, one thread corresponds to one actual runtime delay and one target latency requirement, the p threads are threads competing for the same mutex at the current moment, the p threads run on p cores, one core runs one thread at the current moment, and the p computing powers of the p cores have at least two different computing power values, p≥2. Afterwards, the device further determines the out-of-order waiting queue of the p threads waiting to compete for the mutex based on the p actual runtime delays and the p target latency requirements. After determining the out-of-order waiting queue of the p threads, the device will further determine n target threads based on the p computing powers, p≥n. The p computing power is the computing power of p cores running p threads. One core currently runs one thread. The n target computing powers are all greater than the pn computing power. The n target computing power is the computing power of the n target cores corresponding to the n target threads. The pn computing power is the computing power of the pn cores of the p cores excluding the n target cores. Finally, based on the out-of-order wait queue, the contention queue for the n target threads competing for the mutex is determined, so that the mutex is transferred based on the contention queue.

[0038] In the aforementioned implementations of this application, complex heterogeneous hardware (such as a multi-level AMP system) lacks a static optimal out-of-order strategy, making it impossible to set static priorities based on competitor attributes to optimize throughput. Consequently, good performance scalability cannot be achieved in multi-level AMPs (i.e., when large, medium, and small cores coexist). For multi-level AMP systems, this application proposes a dynamic out-of-order priority mechanism that dynamically prioritizes appropriate competitors at runtime based on competitor attributes (i.e., computing power) and mutex contention, thereby maximizing throughput.

[0039] In one possible implementation of the second aspect, the computing power of each core can be reflected by an assigned score value, and the computing power and the score value are positively correlated. For example, the aforementioned p computing powers can be reflected by the p assigned score values ​​(i.e., they are scored based on their ability to execute critical sections). Then, one implementation method for determining n target threads based on the p computing powers can be: first, determine n target score values ​​greater than a score threshold from the p score values, and then determine the n threads corresponding to the n target score values ​​as the n target threads. In other words, the threads whose score values ​​are greater than the preset score threshold are determined as the target threads.

[0040] In the above-mentioned embodiment of the present application, since the computing power of the core is not easy to quantify, the computing power of the core is reflected by a fractional value, which makes the implementation method simpler.

[0041] In a possible implementation of the second aspect, the method may further include: when the degree of competition for the global mutex does not meet a preset condition, lowering the score threshold according to a preset gradient (which may be referred to as a first preset gradient), wherein the preset condition is used to reflect whether the global mutex is sufficiently competitive.

[0042] In the above-mentioned embodiment of the present application, if the competition is insufficient, the score threshold is lowered so that more threads running on cores with lower computing power can also join the competition queue to improve the throughput.

[0043] In a possible implementation of the second aspect, the method may further include: when the degree of competition for the global mutex lock reaches a preset condition, increasing the score threshold according to a preset gradient (which may be referred to as a second preset gradient), wherein the preset condition is used to reflect whether the global mutex lock is sufficiently competitive.

[0044] In the above-mentioned embodiment of the present application, if the competition is sufficient, the score threshold is increased so that only threads running on cores with higher computing power can join the competition queue to improve the throughput.

[0045] In a possible implementation of the second aspect, the computing power of the core is related to the core type of the core; the larger the core, the greater the computing power.

[0046] In the above-mentioned embodiments of the present application, the core type of the core can be reflected by the computing power.

[0047] In a possible implementation of the second aspect, the p cores include at least two core types.

[0048] In the above implementation of the present application, since the present application is a dynamic out-of-order priority, there must be at least two core types for this solution to be meaningful.

[0049] In a possible implementation manner of the second aspect, the core type includes at least: a large core, a medium core, or a small core.

[0050] In the above embodiments of the present application, several typical core types are specifically described, which have wide applicability.

[0051] In a possible implementation of the second aspect, n target threads run on at least two NUMA nodes, where n ≥ 2. The mutex lock includes a global mutex lock in a NUMA-aware lock. After determining the contention queues of the n target threads competing for the mutex lock based on the out-of-order wait queue, the method may further include: determining n out-of-order requirements for the n target threads based on the n actual runtime latencies and n target latency requirements of the n target threads, wherein each target thread corresponds to one out-of-order requirement, and the out-of-order requirement is used to represent the urgency with which the target thread needs to hold the global mutex lock. Finally, the device determines the out-of-order degree of the global mutex lock based on the obtained n out-of-order requirements, so that the global mutex lock is transferred based on the out-of-order degree, wherein the out-of-order degree is used to represent a threshold for the number of transfers each time the global mutex lock is held. In addition, it should be noted that threads running on the same NUMA node are arranged adjacently on the lock transfer path, so that critical sections of NUMA-local lock competitors can be batched, effectively avoiding frequent cache consistency overhead across NUMA nodes.

[0052] In the above-mentioned embodiment of the present application, when the threads are running, the out-of-order requirements of all competitors (i.e., the n out-of-order requirements of n target threads) are mapped on demand to the global out-of-order degree of the relevant NUMA-aware lock (i.e., the out-of-order degree of the global mutex lock), so that the out-of-order degree of the NUMA-aware lock can be adjusted according to the out-of-order requirements of different threads to meet the latency requirements of all competitors.

[0053] In a possible implementation of the second aspect, an implementation method for determining the disorder degree of the global mutex lock based on n disorder requirements may be: the device updates the disorder degree of the global mutex lock in real time during the transfer process of the global mutex lock based on the disorder requirement of the target thread on the lock transfer path, so that the global mutex lock is transferred based on the real-time updated disorder degree.

[0054] In the above-mentioned embodiment of the present application, the device dynamically updates the disorder degree of the global mutex lock during the global mutex lock transfer process, in order to avoid causing additional overhead on the critical path.

[0055] In a possible implementation of the second aspect, the method may further include: when the disorder degree exceeds a preset time period and is not updated, increasing the value of the disorder degree according to a target preset gradient. For example, when it is found that the upper limit of the number of lock transfers required by the current competitor is smaller (that is, the latency requirement is tighter), the transfer number threshold of the current global mutex lock is updated, otherwise the transfer number threshold remains unchanged. In addition, in order to cope with the target thread with the tightest latency requirement, the value of the transfer number threshold of the global mutex lock can increase over time, or, when the tightest target thread no longer acquires the global mutex lock, the transfer number threshold of the global mutex lock can also slowly increase until the next on-demand update.

[0056] In the above-mentioned embodiment of the present application, when the disorder degree is not updated for a long time, it means that the disorder degree of the global mutex lock is too tight. The disorder degree can be relatively reduced to improve the throughput while ensuring the latency.

[0057] In a possible implementation manner of the second aspect, the out-of-order requirement may be represented by an upper limit on the number of transfers required by the target thread each time the global mutex lock is held.

[0058] In the above implementation of this application, the target threads have different requirements for the degree of out-of-order locks on the global mutex due to latency requirements, contention levels, and other factors. To meet their respective latency requirements, these threads each expect the maximum number of transfers per global mutex lock to be the out-of-order lock requirement of each target thread. This provides flexibility.

[0059] In one possible implementation of the second aspect, a first thread is one of p threads, and the first thread includes m first code snippets with latency requirements, where m ≥ 1. One implementation method for obtaining n actual runtime delays and n target latency requirements for the p threads may be: select a target thread from the p threads as the first thread. Assuming that the first thread includes m (m ≥ 1) code snippets with latency requirements, this code snippet may be referred to as a first code snippet. At the current moment, obtain the first actual runtime delay and first target latency requirement of the first code snippet currently being executed by the first thread; then, using each target thread in the p threads as the first thread, repeat the above steps until obtaining n first actual runtime delays and n first target latency requirements for the n first code snippets currently being executed by each of the p threads.

[0060] In the above-mentioned embodiment of the present application, what is obtained is the actual runtime delay and corresponding delay requirement of the code fragment with delay requirement being executed by each target thread at a specific moment. Therefore, the out-of-order requirement of each target thread is also the current moment. The out-of-order requirement will take different values ​​due to the different code fragments with delay requirements being executed at the current moment, which in turn affects the degree of out-of-order of the subsequent global mutex lock. Therefore, the degree of out-of-order of the global mutex lock is dynamic, real-time, and updated on demand, and is practical.

[0061] A third aspect of the present application provides a device for transferring lock resources. The device is applied to a computer device comprising at least two NUMA nodes. The device has the function of implementing the method of the first aspect or any possible implementation of the first aspect. The function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0062] In a fourth aspect, the present application provides a device for transferring lock resources, which is applied to a computer device, wherein the processor of the computer device includes at least x cores, where x ≥ 2, and the device has the function of implementing the method of the second aspect or any possible implementation of the second aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0063] The fifth aspect of the present application provides a computer device, which may include a memory, a processor, and a bus system, wherein the memory is used to store a computer program (also referred to as a program, computer-readable instructions), and the processor is used to call the program stored in the memory to execute the method of the first aspect of the embodiment of the present application or any possible implementation of the first aspect, or to execute the method of the second aspect of the embodiment of the present application or any possible implementation of the second aspect.

[0064] In a sixth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer, the computer can execute the method of the above-mentioned first aspect or any possible implementation of the first aspect, or the computer can execute the method of the above-mentioned second aspect or any possible implementation of the second aspect.

[0065] In a seventh aspect, the present application provides a computer program or a computer program product containing instructions. When the computer program or computer program product runs on a computer, it enables the computer to execute the method of the above-mentioned first aspect or any possible implementation of the first aspect, or enables the computer to execute the above-mentioned second aspect or any possible implementation of the second aspect.

[0066] In an eighth aspect of the present application, a chip is provided, which includes at least one processor and at least one interface circuit, the interface circuit is coupled to the processor, the at least one interface circuit is used to perform transceiver functions, and send instructions to at least one processor, the at least one processor is used to run a computer program or instruction, which has the function of implementing the method of the first aspect or any possible implementation of the first aspect, or, it has the function of implementing the method of the second aspect or any possible implementation of the second aspect, the function can be implemented by hardware, or by software, or by a combination of hardware and software, the hardware or software includes one or more modules corresponding to the above functions. In addition, the interface circuit is used to communicate with other modules outside the chip.

[0067] In some implementations of the present application, some of the one or more processors may implement some steps of the above method through dedicated hardware. For example, processing involving a neural network model may be implemented by a dedicated neural network processor or a graphics processor.

[0068] The method provided in the embodiment of the present application can be implemented by one chip or by multiple chips working together. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] FIG1 is a system architecture diagram of a delay-guided dynamic out-of-order framework provided in an embodiment of the present application;

[0070] FIG2 is a flow chart of an implementation of the epoch_start interface provided in an embodiment of the present application;

[0071] FIG3 is a flow chart of an implementation of the epoch_end interface provided in an embodiment of the present application;

[0072] FIG4 is a flow chart of a method for transferring lock resources provided in an embodiment of the present application;

[0073] FIG5 is a schematic diagram of an example of a method for transferring lock resources provided in an embodiment of the present application;

[0074] FIG6 is a schematic diagram illustrating an implementation of on-demand alignment of global mutexes provided in an embodiment of the present application;

[0075] FIG7 is a schematic diagram of a locking process of a NUMA-aware lock provided in an embodiment of the present application;

[0076] FIG8 is a schematic diagram of a lock release process of a NUMA-aware lock provided in an embodiment of the present application;

[0077] FIG9 is a schematic diagram of an example of dynamic out-of-order priority provided by an embodiment of the present application;

[0078] FIG10 is a flow chart of a method for transferring lock resources according to an embodiment of the present application;

[0079] FIG11 is a schematic diagram of a locking process of a mutex lock provided in an embodiment of the present application;

[0080] FIG12 is a schematic diagram of a lock releasing process of a mutex provided in an embodiment of the present application;

[0081] FIG13 is a schematic diagram of an example of out-of-order hierarchical management provided by an embodiment of the present application;

[0082] FIG14 is a schematic diagram of a locking process of the LGRF-HETE lock provided in an embodiment of the present application;

[0083] FIG15 is a schematic diagram of a lock release process of a LGRF-HETE lock provided in an embodiment of the present application;

[0084] FIG16 is a flow chart showing a process of increasing the degree of disorder in the disorder adjustment module of the LGRF-HETE lock provided in an embodiment of the present application;

[0085] FIG17 is a flow chart showing a method for reducing the degree of disorder in a disorder adjustment module in an LGRF-HETE lock according to an embodiment of the present application;

[0086] FIG18 is a comparison diagram of the performance of an existing NUMA-aware lock and an LGRF lock provided in an embodiment of the present application;

[0087] FIG19 is a comparative diagram of performance under different tests and different SLO settings provided by an embodiment of the present application;

[0088] FIG20 is a comparative diagram of the performance of the LGRF-AMP provided in an embodiment of the present application under different competition levels;

[0089] FIG21 is a schematic diagram comparing the latency and throughput performance of LGRF in the micro-benchmark test provided by an embodiment of the present application, and the performance under different SLO settings;

[0090] FIG22 is a comparative diagram of performance under different tests and different SLO settings provided by an embodiment of the present application;

[0091] FIG23 is a comparative diagram of the performance of the LGRF-HETE under different competition levels provided in an embodiment of the present application;

[0092] FIG24 is a comparative diagram of the latency and throughput performance of the heterogeneous many-core system provided by an embodiment of the present application in a micro-benchmark test, and the performance under different SLO settings;

[0093] FIG25 is a schematic diagram comparing performance under different tests and different SLO settings provided by an embodiment of the present application;

[0094] FIG26 is a schematic structural diagram of a device provided in an embodiment of the present application;

[0095] FIG27 is another schematic structural diagram of the device provided in an embodiment of the present application;

[0096] Figure 28 is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0097] Embodiments of the present application provide a lock resource transfer method, apparatus, and computer device for mapping the out-of-order requirements of all competitors to the global out-of-order degree of the associated NUMA-aware lock as needed during thread execution, thereby eliminating the semantic gap. Specifically, when competitors exist for the same global mutex, the out-of-order degree (i.e., global out-of-order degree) that should be set for the global mutex can be determined based on whether the competitors have latency requirements and the actual latency requirements during execution, thereby meeting the latency requirements of all competitors.

[0098] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0099] The embodiments of this application involve knowledge related to mutual exclusion locks. In order to better understand the solutions of the embodiments of this application, the following first introduces the relevant terms and concepts that may be involved in the embodiments of this application. It should be understood that the interpretation of relevant terms and concepts may be limited by the specific circumstances of the embodiments of this application, but it does not mean that this application is limited to only such specific circumstances. The specific circumstances of different embodiments may also vary, which is not specifically limited here.

[0100] (1) Mutex

[0101] Mutex locks are a common synchronization primitive. They are used to provide mutually exclusive access guarantees in multi-threaded applications. When multiple threads need to modify shared data (such as the same entry in a database), they use a mutex lock to ensure that only one thread can modify the shared data at a time.

[0102] Mutexes may exist in different forms in different systems. For example, in a NUMA system, a mutex is represented by a NUMA-aware lock (e.g., a cohort lock). A NUMA-aware lock consists of one global mutex and w local mutexes. The number of local mutexes w corresponds to the NUMA node, with one local mutex per NUMA node. (For the same critical section, multiple NUMA-aware locks can exist for different critical sections.) For another example, in an asymmetric multiprocessor (AMP) system, a mutex can be represented by the asymmetric-aware mutex LibASL.

[0103] (2) Critical section

[0104] The code area protected by a mutex is called a critical section. Only one thread can enter the critical section at a time. An application can have multiple mutexes, and each mutex corresponds only to a critical section.

[0105] (3) Competition level

[0106] The degree of contention describes how many threads are competing for the same mutex lock at any given time. When the degree of contention is low, threads spend less time waiting and can directly acquire the mutex lock and enter the critical section. At this point, the locking mechanism has a limited impact on the application, primarily due to overhead such as the lock acquisition and release processes and lock metadata allocation. When the degree of contention is high, a large number of threads are waiting for the lock-holding thread to release the lock, significantly impacting application performance.

[0107] (4) Tail delay

[0108] This refers to a series of operations where the latency of a small number of requests is higher than the average latency of all requests. For example, P99 tail latency means that 99% of the requests have a latency lower than this value (i.e., the latency of the 99th percentile request, sorted in ascending order).

[0109] (5) Critical Path

[0110] The critical path is the execution flow that determines the runtime of an application. When multiple threads frequently compete for mutex locks, the application's critical path includes the lock transfer process and the execution of critical sections.

[0111] (6) Latency service level objective (SLO)

[0112] Latency SLOs are service-level objectives for application latency. For example, suppose a cloud provider guarantees a 200ms latency SLO for a database request, meaning that 99% of the time, the tail latency of that database request will not exceed 200 milliseconds.

[0113] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate 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.

[0114] First, the system architecture and overall process applied by the method of the embodiment of the present application are described. Please refer to Figure 1 for details. Figure 1 is a system architecture diagram of the latency guided reordering framework (LGRF) provided in the embodiment of the present application. The LGRF can be used in systems such as NUMA systems, multi-level AMP (multi-level means that the core types include at least three types, such as large cores, medium cores, and small cores) systems, and heterogeneous multi-core (i.e., multi-level AMP and NUMA characteristics exist at the same time) systems. That is, LGRF can be implemented on different specific platforms.

[0115] For different heterogeneous platforms, accessing LGRF requires the implementation of two modules: a controllable out-of-order lock 101 and a corresponding out-of-order adjustment module 102. Among them, the controllable out-of-order lock 101 is adjusted according to the out-of-order requirements of each given target thread (per thread per epoch) so that the out-of-order lock competitor obtains throughput benefits, while the out-of-order adjustment module 102 is used to update the out-of-order requirements recorded in each thread per epoch. In addition, in some embodiments of the present application, LGRF also has the following requirements for specific heterogeneous implementations:

[0116] The degree of out-of-order lock 101 is positively correlated with latency and throughput. LGRF relies on the assumption that increasing the out-of-order lock will increase lock acquisition latency and correspondingly improve throughput. Based on this assumption, LGRF uses feedback regulation to find the appropriate out-of-order lock to maximize throughput. Therefore, the controllable out-of-order lock 101 for a specific heterogeneous system must meet this assumption.

[0117] b. When making out-of-order decisions, the controllable out-of-order lock 101 must consider the out-of-order requirements of all threads currently competing for the same critical section. In LGRF, the degree of out-of-order is determined by each thread based on its own timeout conditions, thus creating a per-thread private out-of-order requirement. When making out-of-order decisions, the controllable out-of-order lock 101 must consider the out-of-order requirements of all competing threads to avoid exceeding latency limits for any of them.

[0118] Based on the above two assumptions, the following describes how LGRF collects the actual runtime latency of each thread and how to adjust the out-of-order degree of the controllable out-of-order lock 101 based on the actual runtime latency and latency requirements:

[0119] To maximize the degree of mutex out-of-order locks while meeting the application's latency requirements, LGRF first collects the coarse-grained latency requirements of each thread in the application (an application can contain multiple threads). As shown in Figure 1, LGRF marks a code snippet with latency requirements as an epoch (a thread can contain multiple code snippets) and provides two intuitive and easy-to-use interfaces, epoch_start and epoch_end, to wrap the code snippet. The latency requirement of the code snippet can be given as a latency SLO, which is measured in nanoseconds (ns) (e.g., 50 means 99% of requests should be completed within 50ns) and passed to LGRF via the epoch_end interface. The application marks the code snippet by additionally calling this interface and passes the latency requirement of the code snippet to LGRF via the epoch_end parameter. LGRF will adjust the degree of out-of-order locks (i.e., the controllable out-of-order lock 101) at runtime based on the actual runtime latency of the code snippet, thereby ensuring the coarse-grained latency requirements. Specifically, when actually running a code snippet wrapped in a certain epoch, if the actual runtime latency (i.e., the runtime latency of the code snippet + the lock acquisition latency) is less than the set coarse-grained latency requirement, the mutex lock out-of-order level is increased. This is because increased out-of-order levels increase the time threads spend waiting for locks, ultimately increasing the actual runtime latency. For example, in a NUMA system, increasing out-of-order levels is reflected by increasing the global mutex lock transfer threshold. Conversely, if the actual runtime latency is greater than the set coarse-grained latency requirement, the out-of-order level is reduced. Similarly, in a NUMA system, reducing out-of-order levels is reflected by reducing the global mutex lock transfer threshold.

[0120] To facilitate understanding of the latency requirements described above, let's use a specific example. For example, assume an application A contains four threads. Thread 1 contains code snippets 11, 12, and 13, with snippet 11 labeled epoch 1. Thread 2 contains code snippets 21, 22, 23, and 24, with snippets 22 and 23 labeled epoch 2 and epoch 3, respectively. Thread 3 contains code snippets 31 and 32, with snippet 32 ​​labeled epoch 4. Thread 4 contains code snippets 41, 42, 43, and 44, with snippets 41 and 44 labeled epoch 5 and epoch 6, respectively. The coarse-grained latency requirement for application A is the latency requirement for executing the code snippets enclosed in each of these six epochs (i.e., epoch 1 to epoch 6), for a total of six latency requirements.

[0121] In the embodiment of the present application, LGRF collects the actual runtime latency of each thread on the application and adjusts the degree of disorder by using the epoch_start interface and the epoch_end interface. As an example, the execution process of epoch_start and the execution process of epoch_end are described below:

[0122] a. Implementation of epoch_start interface

[0123] For details, please refer to Figure 2, which is a flowchart of the implementation of the epoch_start interface provided in an embodiment of the present application. When the LGRF calls the epoch_start interface, the following steps are performed:

[0124] 201. Record the epoch start timestamp.

[0125] First, when the thread executes the code fragment wrapped by the epoch, the timestamp of the start of the epoch is recorded.

[0126] 202. Set the current epoch identifier (per thread).

[0127] After that, the epoch identifier is set, which is used to uniquely identify the epoch. Note that the epoch identifier is per thread.

[0128] 203. Epoch begins.

[0129] Finally, start executing the code snippet wrapped by the epoch.

[0130] b. Implementation of epoch_end interface

[0131] For details, please refer to Figure 3, which is a flowchart of the epoch_end interface implementation provided by an embodiment of the present application. When the LGRF calls the epoch_end interface, the following steps are performed:

[0132] 301. Calculate the actual runtime delay of the epoch.

[0133] First, the actual runtime latency of the epoch is calculated based on the current timestamp and the recorded epoch start timestamp. The calculation method is: actual runtime latency = current timestamp time - epoch start timestamp time.

[0134] 302. Determine whether the current actual running delay is greater than the set delay SLO. If so, execute step 304; if not, execute step 303.

[0135] Afterwards, it is further determined whether the current actual running delay is greater than the set delay SLO. If so, step 304 is executed; if not, step 303 is executed.

[0136] 303. Call the interface that increases the degree of disorder.

[0137] If it is determined that the current actual running delay is less than or equal to the set delay SLO, an interface for increasing the reordering degree is called. This interface can be provided by the controllable reordering lock 101 of a specific platform. For example, this interface can be expressed as increase_reorder.

[0138] 304. Call the interface that reduces the degree of disorder.

[0139] If it is determined that the current actual running delay is greater than the set delay SLO, the interface for reducing the degree of reordering is called. Similarly, the interface can also be provided by the controllable reorder lock 101 of the specific platform, such as the interface can be expressed as decrease_reorder.

[0140] 305. Epoch ends.

[0141] Finally, end the current epoch.

[0142] It is important to note that the epoch_end API implementation can be repeated. For example, if this is the first calculation of the actual runtime latency of epoch 1, and if the result of implementing this API is to increase the degree of out-of-orderness, then the repeated execution refers to the second calculation of the actual runtime latency of epoch 1.

[0143] It should also be noted that in some embodiments of the present application, when pthread_mutex_lock (as shown in FIG1 ) is called in an application, LGRF can replace it with the locking operation of the controllable out-of-order lock 101 of the corresponding platform in LGRF through weak symbol replacement. This operation will select an appropriate out-of-order strategy for the controllable out-of-order lock 101 based on the hardware characteristics of the corresponding platform and the epoch in which it is located, maximizing out-of-order to improve throughput while meeting latency requirements.

[0144] Based on the above system architecture, the following describes the lock resource transfer methods provided in the embodiments of the present application for different heterogeneous platforms.

[0145] A. LGRF accesses the NUMA system.

[0146] In this case, the controllable out-of-order lock 101 is a NUMA-aware lock, also known as an LGRF-NUMA lock, and its out-of-order degree is characterized by the global out-of-order degree of the NUMA-aware lock (i.e., the out-of-order degree of the global mutex lock). For details, please refer to Figure 4, which is a flow chart of a lock resource transfer method provided in an embodiment of the present application, which may include the following steps:

[0147] 401. Obtain n actual runtime latencies and n target latency requirements of n target threads, where the n target threads are threads currently competing for the same global mutex, and the n target threads run on at least two NUMA nodes, where n ≥ 2.

[0148] First, the device (such as the device deployed with the above-mentioned LGRF) will first obtain n actual runtime delays and n target latency requirements of n target threads, where one target thread corresponds to one actual runtime delay and one target latency requirement. The n target threads are threads competing for the same global mutex at the current moment. These n target threads run on at least two NUMA nodes, and n ≥ 2.

[0149] For example, assuming that the global mutex lock corresponding to critical section Z1 is S1, and assuming that at the current moment, threads a and b running on NUMA node 1, and thread c running on NUMA node 2 (i.e., n=3) all need to access critical section Z1, this means that these three threads need to compete for the global mutex lock S1 at the current moment. In this case, the device will first obtain the actual runtime latency of each of the three threads and their corresponding target latency requirements (assuming that all three threads have latency requirements). In one implementation, this can be obtained based on the system architecture of Figure 1 above, which is not described in detail in this application.

[0150] 402. Determine n out-of-order requirements of n target threads based on the n actual runtime delays and the n target delay requirements. The out-of-order requirements are used to represent the urgency with which the target threads need to hold the global mutex lock.

[0151] Afterwards, the device further determines n out-of-order requirements of the n target threads based on the obtained n actual runtime delays and n target delay requirements, wherein one target thread corresponds to one out-of-order requirement, and the out-of-order requirement is used to characterize the urgency of the target thread's need to hold the global mutex lock.

[0152] Continuing with the example in step 401, after obtaining the actual runtime latencies and corresponding target latency requirements of threads a, b, and c, the device determines the out-of-order requirements for each of these three threads based on the actual runtime latencies and corresponding target latency requirements. Specifically, it determines out-of-order requirement A1 for thread a, B1 for thread b, and C1 for thread c. Each out-of-order requirement represents the urgency with which the corresponding target thread needs to hold the global mutex.

[0153] It should be noted that in some embodiments of the present application, the out-of-order requirement can be represented by the upper limit on the number of transfers required by the target thread each time the global mutex lock is held. Still using the above example, assuming the out-of-order requirement A1 is 100, this means that thread a expects the upper limit on the number of transfers required by the target thread each time the global mutex lock S1 is held is 100.

[0154] For ease of explanation, in the subsequent description, the upper limit of the number of transfers required by the target thread each time the global mutex is held is used to represent the out-of-order requirement of each target thread, and no further details are given.

[0155] It should also be noted that in some embodiments of the present application, since each target thread may have multiple code snippets with latency requirements (i.e., the epochs described above), obtaining the n actual runtime latencies and n target latency requirements of n target threads refers to obtaining the actual runtime latency and corresponding target latency requirements of the code snippets being executed by each target thread at a specific moment. Therefore, the out-of-order requirement of each target thread is also current, and this out-of-order requirement will take different values ​​depending on the epoch being executed at the current moment, thereby affecting the out-of-order degree of the subsequent global mutex lock. Therefore, the out-of-order degree of the global mutex lock is updated dynamically, in real time, and on demand.

[0156] The specific acquisition process may be as follows: select a target thread from n target threads as the first thread. Assuming that the first thread includes m (m ≥ 1) code snippets with latency requirements, this code snippet may be referred to as the first code snippet. At the current moment, obtain the first actual runtime latency and the first target latency requirement of the first code snippet currently being executed by the first thread. Then, using each of the n target threads as the first thread, repeat the above steps until obtaining n first actual runtime latencies and n first target latency requirements for the n first code snippets currently being executed by each of the n target threads.

[0157] To facilitate understanding of the above process, let's use an example. Assume that thread a consists of four code snippets: snippet a1, snippet a2, snippet a3, and snippet a4. Snippets a2 and a3 are enclosed in epochs: epoch1 and epoch2, respectively. The latency requirement for epoch1 corresponds to an upper limit of 5 global mutex lock transfers, while the latency requirement for epoch2 corresponds to an upper limit of 30 global mutex lock transfers. Therefore, when thread a executes epoch1, the out-of-order requirement for time 1 is 5. When thread a executes epoch2, the out-of-order requirement for time 2 dynamically increases to 30.

[0158] 403. Determine the disorder degree of the global mutex lock according to the n disorder requirements, so that the global mutex lock is transferred based on the disorder degree. The disorder degree is used to represent a threshold of the number of transfers each time the global mutex lock is held.

[0159] Finally, the device determines the disorder degree of the global mutex lock based on the n disorder requirements obtained, so that the global mutex lock is transferred based on the disorder degree, wherein the disorder degree is used to characterize the threshold of the number of transfers each time the global mutex lock is held. In addition, it should be noted that threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path, so that the critical sections of the NUMA local lock competitors can be batched, which can effectively avoid the frequent cache consistency overhead across NUMA nodes.

[0160] It should be noted that, in the embodiment of the present application, there are different implementation methods for determining the disorder degree of the global mutex lock according to the n disorder requirements, including but not limited to the following methods:

[0161] a. After obtaining all n out-of-order requirements, determine the out-of-order degree of the global mutex lock.

[0162] In the implementation of the present application, the device determines the disorder degree of the global mutex lock after obtaining all n disorder requirements.

[0163] To facilitate understanding of this process, a specific example is used below for illustration. Specifically, please refer to FIG5 , which is a schematic diagram illustrating an example of a lock resource transfer method provided in an embodiment of the present application. In FIG5 , assume that three threads are currently running: thread a, thread b, and thread c. Different shapes represent different core types running the corresponding threads, and different padding indicates that the threads are running on different NUMA nodes. Due to latency requirements, contention levels, and other factors, these threads have different requirements for the global out-of-order degree of NUMA-aware locks (i.e., the out-of-order degree of global mutex locks). To meet their respective latency requirements, these threads each wish to set the upper limit on the number of transfers of the global mutex lock (referred to as the transfer limit) to 100, 5 (tightest), and 200 (loosest). Thread a acquires two NUMA-aware locks (i.e., LGRF-NUMA-1 and LGRF-NUMA-2, which include a global mutex and a local mutex) at different times. At a certain moment, LGRF-NUMA-1 is simultaneously contested by thread a and thread c. In contrast, thread a has a tighter out-of-order requirement, so the upper limit of the transfer count threshold of LGRF-NUMA-1 (the lock threshold corresponding to LGRF-NUMA-1 as shown in Figure 5) should be set to 100. At another moment, LGRF-NUMA-2 is simultaneously contended by thread a and thread b, and at this time, thread b has a tighter out-of-order requirement, so LGRF-NUMA-2 should set the upper limit of its transfer count threshold (the lock threshold corresponding to LGRF-NUMA-2 as shown in Figure 5) to 5 according to thread b's out-of-order requirement.

[0164] This strategy ensures that the global out-of-order degree of NUMA-aware locks is determined by the out-of-order requirements of all competitors. This rule updates the threshold of the global mutex lock by tracking all competitors with latency requirements and comparing their out-of-order requirements in real time.

[0165] b. Update the disorder degree of the global mutex lock in real time according to the disorder requirements of the target thread on the lock transfer path.

[0166] In the implementation of this application, to avoid incurring additional overhead on the critical path, the device dynamically updates the out-of-order degree of the global mutex lock during the global mutex lock transfer process. Specifically, the device updates the out-of-order degree of the global mutex lock in real time during the global mutex lock transfer process based on the out-of-order requirements of the target thread on the lock transfer path, so that the global mutex lock is transferred based on the real-time updated out-of-order degree.

[0167] Specifically, each global mutex has its own disorder setting (i.e., the number of transfers threshold). The number of transfers threshold will only be updated when it is transferred to a competitor with a latency requirement. For example, when it is found that the upper limit of the number of lock transfers required by the current competitor is smaller (i.e., the latency requirement is tighter), the number of transfers threshold of the current global mutex is updated, otherwise the number of transfers threshold remains unchanged. In addition, in order to cope with the target thread with the tightest latency requirement, the value of the number of transfers threshold of the global mutex can increase over time, or, when the tightest target thread no longer acquires the global mutex, the number of transfers threshold of the global mutex can also slowly increase until the next on-demand update. In summary, when the disorder level exceeds the preset time length and is not updated, the device can increase the value of the disorder level of the global mutex according to the target preset gradient.

[0168] Through this method, the degree of disorder of the global mutex lock can be set as needed according to the disorder requirement of the competitor with the tightest latency requirement within a certain period of time.

[0169] To facilitate understanding of the above-mentioned process of setting the degree of disorder of the global mutex lock on demand, a specific example is used as an example for explanation. Please refer to Figure 6 for details. Figure 6 is a schematic diagram of an implementation of the on-demand alignment of the global mutex lock provided by the embodiment of the present application. In Figure 6, there are 6 lock competitors on two NUMA nodes competing for the same global mutex lock, namely competitor 1, competitor 2, competitor 3, competitor 4, competitor 5, and competitor 6. Among them, at the current moment, competitor 2, competitor 3, and competitor 5 have a delay requirement. When the global mutex lock is transferred for the first time (from competitor 1 to competitor 2), its disorder threshold is assumed to be set to 100 by default, and the number of local transfers at this time is 1. Since competitor 2 has a delay requirement, and the upper limit of the number of transfers required to meet the delay requirement (4) is lower than the default transfer threshold (100) set for the current global mutex lock, the transfer threshold of the global mutex lock is reduced to 4 during the second transfer. During the third transfer, although competitor 3 also has a latency requirement, it is more relaxed than competitor 2. Therefore, in order to meet the stricter latency requirement of competitor 2, the transfer threshold of the global mutex lock remains at 4, and reaches the transfer threshold after being transferred to competitor 4 and released to node 1. In addition, the transfer threshold of the global mutex lock can be slowly increased and updated to 4+x at this time, where x is the target preset gradient. For example, when x=1, it means that it is automatically increased to 5. Correspondingly, since competitor 5 has a tighter latency requirement, the transfer threshold will be further reduced to 3. It should be noted here that this application does not limit the conditions for updating the transfer threshold of the global mutex lock. It can be updated when crossing NUMA nodes, or it can be updated when the global mutex lock is not updated after y times (i.e., the preset number of times). This application does not limit this.

[0170] To further understand the solution of the present application, the locking process and the releasing process of the NUMA-aware lock (i.e., LGRF-NUMA lock) of the present application are described in detail from the perspective of threads.

[0171] 1. Locking process of NUMA-aware locks.

[0172] Please refer to Figure 7 for details. Figure 7 is a schematic diagram of a locking process for a NUMA-aware lock according to an embodiment of the present application. The process may include the following steps:

[0173] 701. Acquire the local mutex of the NUMA-aware lock.

[0174] First, the target thread acquires the local mutex of the NUMA node where the target thread is located.

[0175] 702. Determine whether the waiting queue is empty. If so, execute step 705; if not, execute step 703.

[0176] The target thread further determines whether it is the first thread on the NUMA node to compete for the local mutex lock. This can be achieved by determining whether the waiting queue of the local mutex lock is empty. If the waiting queue is empty, step 705 is executed; if the waiting queue is not empty, step 703 is executed.

[0177] It should be noted here that if the waiting queue is empty, it means that the target thread is the first thread to obtain the local mutex on the NUMA node. The first thread to obtain the local mutex on each NUMA node needs to compete for the global mutex. After competing for the global mutex, the global mutex remains on the NUMA node until the number of times the local mutex is transferred in each thread reaches the local transfer threshold of the local mutex (referred to as the local threshold). It is assumed here that the local threshold is less than the transfer threshold of the global mutex (referred to as the global threshold); if the local threshold is greater than the global threshold, the global mutex remains on the NUMA node until the number of times the local mutex is transferred in each thread reaches the global threshold and must be released.

[0178] 703. Obtain a threshold value of the number of transfers of the transferred global mutex lock.

[0179] If the waiting queue is not empty, it means that the target thread is not the first thread to obtain the local mutex on the NUMA node. In this case, the target thread obtains the transfer count threshold passed from the previous global mutex holder.

[0180] 704. Determine whether a global mutex lock needs to be acquired. If so, execute step 705; if not, execute step 709.

[0181] The target thread determines whether it needs to acquire the global mutex (set by the previous holder of the global mutex). If so, step 705 is executed; if not, step 709 is executed.

[0182] 705. Acquire the global mutex lock.

[0183] The target thread acquires the global mutex lock.

[0184] 706. Determine whether the global mutex is empty when it is acquired. If so, execute step 707; if not, execute step 708.

[0185] The target thread further determines whether the global mutex is empty when it is acquired. If so, step 707 is executed; if not, step 708 is executed.

[0186] It should be noted that this step focuses on whether the global mutex lock was acquired directly or after the target thread waited for a period of time (i.e., whether it was passed from the previous holder). In other words, this step actually determines whether the global mutex lock was passed from the previous thread or was empty when the target thread acquired it. If it was passed from the previous thread, a transfer count threshold will be updated during the transfer process. If it was empty when acquired, there is no transfer count threshold.

[0187] 707. Set the global mutex lock transfer count threshold to the default threshold, and set the local transfer count to 0.

[0188] The target thread sets the transfer count threshold of the global mutex lock to the default threshold, and sets the local transfer count to 0, and then goes to step 709 .

[0189] 708. Inherit the global mutex lock transfer count threshold from the previous global mutex lock holder and add 1 to it, and set the local transfer count to 0.

[0190] The target thread inherits the transfer count threshold of the previous global mutex lock holder and adds 1 (ie, slowly increases), and sets the local transfer count to 0, and then goes to step 709.

[0191] 709. Set the number of local transfers +1 and successfully hold the NUMA-aware lock.

[0192] The target thread sets the local transfer count + 1 and successfully obtains the NUMA-aware lock.

[0193] 2. NUMA-aware lock release process.

[0194] Please refer to Figure 8 for details, which is a schematic diagram of a NUMA-aware lock release process according to an embodiment of the present application. The process may include the following steps:

[0195] 801. Update the current global mutex transfer count threshold according to the out-of-order requirement of the current target thread.

[0196] The target thread updates the transfer count threshold of the global mutex lock according to the current out-of-order requirement of the target thread. Specifically, if the out-of-order requirement of the current target thread is tighter (i.e., the upper limit of the required transfer count of the global mutex lock is smaller), the transfer count threshold of the current global mutex lock is set to the upper limit of the transfer count of the global mutex lock required by the current target thread; otherwise, the transfer count threshold of the global mutex lock remains unchanged.

[0197] 802. Release the local mutex of the NUMA node and pass the current transfer count threshold of the global mutex.

[0198] The target thread releases the local mutex of the NUMA node and passes the current global mutex pass count threshold.

[0199] 803. Determine whether there is a subsequent node. If so, execute step 804; if not, execute step 805.

[0200] It is further determined whether there is a subsequent node. If so, step 804 is executed; if not, step 805 is executed.

[0201] 804. Determine whether the number of local transfers exceeds the upper limit. If so, execute step 805; if not, execute step 806.

[0202] In addition, it is necessary to further determine whether the number of local transmissions exceeds the upper limit. If so, execute step 805; if not, execute step 806.

[0203] 805. Release the global mutex lock and pass the current global mutex lock transfer count threshold.

[0204] The target thread releases the global mutex lock and passes the current global mutex lock transfer count threshold.

[0205] 806. Successfully released the NUMA-aware lock.

[0206] The target thread successfully released the NUMA-aware lock.

[0207] It should also be noted that in some embodiments of the present application, the NUMA-aware lock reordering module can adjust the reordering degree of the global mutex lock using a linear growth exponential backoff method. Specifically, when the actual execution latency of the target thread exceeds the target latency requirement (calling decrease_reorder), it directly halves the upper limit of the global mutex lock transfer count required by the current epoch; otherwise (calling increase_reorder), it slowly increases the threshold. Due to the use of an on-demand alignment method, the upper limit of the global mutex lock transfer count required by the epoch is not directly transferred to the global mutex lock. Each target thread has a private upper limit requirement for the number of transfers for each global mutex lock. When there is no latency requirement among the global mutex lock competitors, the transfer count threshold of the global mutex lock will slowly increase. Only when there is a latency requirement among the competitors will the private upper limit of the number of transfers here be aligned to the transfer count threshold of the global mutex lock.

[0208] In summary, for NUMA systems, this application proposes a global out-of-order alignment technology that maps the out-of-order requirements of all competitors to the global out-of-order degree of the relevant NUMA-aware lock on demand during runtime. Specifically, when there are competitors for NUMA-aware locks, they can be distinguished based on whether the competitors have latency requirements (i.e., whether the thread is executing an epoch), and the global out-of-order degree that should be set can be determined accordingly. When all lock competitors have no latency requirements, the out-of-order degree of the NUMA-aware lock can be set to the maximum value to maximize throughput; and when some or all of the lock competitors have latency requirements, the out-of-order degree of the NUMA-aware lock should be set to the strictest out-of-order requirement among all competitors to meet the latency of all competitors.

[0209] It should be noted that, in some embodiments of the present application, the n target threads described in the above embodiment can be determined from p (p≥n) threads, and the p threads are threads competing for the same global mutex lock at the current moment, wherein the n target threads are the threads in the competition queue at the current moment, and the remaining pn threads are out-of-order waiters, waiting to join the competition queue later to compete for the above global mutex lock.

[0210] It should be noted that, in the embodiment of the present application, there are various ways to determine n target threads from p threads, including but not limited to:

[0211] a. Determined based on the FIFO principle.

[0212] In this scenario, the queues competing for the same global mutex are selected from p threads based on the FIFO principle. This single-queue lock is immediately entered into the Linux kernel. A specific implementation could be a global FIFO queue that, when releasing a lock, traverses the queue to search for locks from the same NUMA node and prioritizes them. If the number of locks exceeds a threshold, the lock is passed directly to the next node. This threshold can be controlled to control the transfer of global mutex locks.

[0213] b. Determined based on the computing power of the core running the thread.

[0214] In this case, what actually corresponds to the situation where LGRF is connected to a heterogeneous multi-core system (i.e., there are multi-level AMP and NUMA features at the same time). The implementation principle is: each core can only run one thread at the same time. Due to the different types of cores, the computing power of the corresponding cores is also different. When there are p threads running on p cores competing for the same global mutex at the current moment, only the threads running on the cores whose computing power reaches the threshold can join the competition queue. For example, the computing power of the corresponding cores of the n target threads reaches the threshold, and the remaining pn threads automatically become out-of-order waiters, waiting to join the competition queue later to compete for the above-mentioned global mutex. Specifically, the device determines n target threads based on p computing powers, where p computing powers are the computing powers of the p cores running p threads, one core runs one thread at the current moment, and the n target computing powers are all greater than pn computing powers. The n target computing powers are the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers are the computing powers of the pn cores in the p cores excluding the n target cores.

[0215] It should be noted that in the above embodiment of the present application, since the computing power of the core is not easy to quantify, the computing power of each core can be reflected by the assigned score value, and the computing power size is positively correlated with the score value. For example, the above-mentioned p computing powers can be reflected by the assigned p score values ​​(that is, they are scored according to their ability to execute critical sections). One way of assigning values ​​can be: the score ratio of different cores is the same as their computing power ratio. For example, in an asymmetric processor with large, medium and small cores, if its computing power ratio is 3:2:1, then its score ratio is also set to 3:2:1, and the corresponding score values ​​can be assigned to 300, 200, 100, or 600, 400, 200. This application does not limit this. Accordingly, the implementation method for the device to determine n target threads based on p computing powers can be: first, determine n target score values ​​with values ​​greater than the score threshold from the p score values, and then determine the n threads corresponding to the n target score values ​​as the said n target threads. That is, the thread whose score value is greater than the preset score threshold is determined as the target thread.

[0216] It should be noted that in some embodiments of this application, the computing power of a core is related to its core type: the larger the core, the greater the computing power. It should be noted that in this embodiment of the application, cores of the same core type have the same computing power by default. Since this embodiment of the application determines n target threads from p threads based on computing power, there are at least two core types among the p cores mentioned above. Core types can include: large core, medium core, and small core.

[0217] It should also be noted that in some embodiments of the present application, the appropriate core type can be prioritized based on the contention level at runtime to achieve the highest throughput (i.e., dynamic out-of-order prioritization). Specifically, when the contention level for the global mutex does not meet a preset condition, the score threshold is lowered according to a preset gradient (which may be referred to as a first preset gradient); conversely, when the contention level for the global mutex meets a preset condition, the score threshold is increased according to a preset gradient (which may be referred to as a second preset gradient). The preset condition reflects whether the global mutex is sufficiently contested. In other words, the device selects a minimum score threshold that ensures sufficient contention for the global mutex, i.e., only competitors with a score greater than this threshold are allowed to compete for the global mutex, without causing the global mutex to become idle. Because factors such as the contention level for the global mutex and the attributes of the competitors are constantly changing, the score threshold for the global mutex is dynamically adjusted at runtime. As an example, if the tail pointer of the currently prioritized queue is null, this indicates that the current score threshold is too high, resulting in insufficient contention for the global mutex. In this case, the score threshold should be lowered to allow more competitors to join the competition. On the contrary, as an example, if the global mutex lock is transferred and it is found that the subsequent competitor has arrived before the current lock holder enters the critical section, it means that the global mutex lock has been fully contended. At this time, the threshold should be appropriately raised to allow more high-computing power competitors to hold the global mutex lock on the critical path to improve throughput.

[0218] In the embodiment of the present application, the preset conditions are used to reflect whether the global mutex lock is sufficiently competitive. The situations that indicate whether the competition is sufficient include but are not limited to the following:

[0219] Case 1: If the current competition queue is empty, it indicates insufficient competition; otherwise, it indicates sufficient competition.

[0220] Case 2: If the number of consecutive transfers of the global mutex exceeds the threshold, it indicates sufficient competition; otherwise, it indicates insufficient competition.

[0221] Case 3: The core types of the target threads running in the global mutex record, for example, if they are all large cores, it means that the competition is sufficient; if there are at least two core types, it means that the competition is insufficient.

[0222] Case 4: For the same target thread, the time interval between the current global mutex lock release and the next global mutex lock holding is less than the threshold, indicating insufficient competition; conversely, the time interval is greater than the threshold, indicating sufficient competition.

[0223] Case 5: The duration between the time when the target thread calls the lock operation and the time when the target thread successfully obtains the global mutex lock. If the duration exceeds the threshold, the longer the duration, the more sufficient the competition; otherwise, it means that the competition is insufficient.

[0224] To facilitate understanding of the above process, the process of dynamic out-of-order priority is described below with a specific example. Please refer to Figure 9 for details. Figure 9 is a schematic diagram of an example of dynamic out-of-order priority provided by an embodiment of the present application. In Figure 9, the competitors of the global mutex lock come from the large core, medium core and small core respectively, and their computing power ratio is 3:2:1. Therefore, the large core, medium core and small core competitors can be given 600 points, 400 points and 200 points respectively. At the current moment, the real-time score threshold for joining the competition queue is 401, that is, only the large core competitor can join the competition queue (that is, the priority acquisition queue in Figure 9), and the medium core and small core competitors can only become out-of-order waiters, and all out-of-order waiters constitute an out-of-order waiting queue. At this time, the global mutex lock is held by the large core competitor, and the tail pointer of the waiting queue points to the competitor, which means that there are no subsequent competitors in the waiting queue, and the global mutex lock is not fully contested. To allow more high-score competitors to fully compete for the global mutex and prevent all out-of-order waiters from grabbing the lock when the global mutex is idle, the score threshold of the contention queue is reduced from 401 to 400 (the reduction is customizable and is only illustrative). Therefore, newly arrived mid-core competitors can join the contention queue, while small-core competitors are unable to join and continue to be out-of-order waiters.

[0225] Through this mechanism, the device can increase the score threshold as much as possible according to the degree of competition at runtime, while fully competing for the global mutex lock, thereby improving the processing performance of competitors on the lock-holding critical path and improving the throughput of the global mutex lock.

[0226] B. LGRF is connected to the multi-level AMP system.

[0227] In this case, the controllable out-of-order lock 101 is an asymmetric sensing lock, which can also be called a mutual exclusion lock or an LGRF-AMP lock. Please refer to Figure 10 for details. Figure 10 is a flow chart of a lock resource transfer method provided in an embodiment of the present application, which can specifically include the following steps:

[0228] 1001. Obtain p actual runtime latencies and p target latency requirements of p threads, where the p threads are threads currently competing for the same mutex lock, the p threads are running on p cores, and the p computing powers of the p cores have at least two different computing power values, where p ≥ 2.

[0229] First, the device (such as the device deployed with the above-mentioned LGRF) will obtain p actual runtime delays and p target latency requirements of p threads. One thread corresponds to one actual runtime delay and one target latency requirement. The p threads are threads competing for the same mutex at the current moment. The p threads run on p cores, and one core runs one thread at the current moment. The p computing powers of the p cores have at least two different computing power values, p ≥ 2.

[0230] For example, assuming that the mutex lock corresponding to critical section Z2 is S2, and assuming that at the current moment, thread a running on core 1, thread b running on core 2, thread c running on core 3, and thread d running on core 4 (i.e., p=4) all need to access critical section Z2, it means that these four threads need to compete for mutex lock S2 at the current moment, then the device will first obtain the actual running delay of each of the four threads and their corresponding target latency requirements (assuming that these four threads have latency requirements). In one implementation, it can be obtained based on the system architecture of Figure 1 above, which is not elaborated in this application.

[0231] 1002. Determine, based on the p actual runtime delays and the p target delay requirements, an out-of-order waiting queue of the p threads waiting to compete for the mutex lock.

[0232] The device then further determines the out-of-order waiting queue for the p threads competing for the mutex lock based on the p actual runtime delays and the p target latency requirements. This process actually determines the order of each out-of-order waiter in the out-of-order waiting queue. Specifically, the maximum allowable waiting time for each out-of-order waiter is determined based on the p actual runtime delays and the p target latency requirements. Threads with shorter waiting times are placed at the front of the out-of-order waiting queue; conversely, threads with longer waiting times are placed at the back of the out-of-order waiting queue. In other words, the out-of-order waiting queue is arranged based on waiting time.

[0233] 1003. Determine n target threads based on p computing powers, where p ≥ n.

[0234] After determining the out-of-order waiting queues for p threads, the device will further determine n target threads based on the p computing powers, where p ≥ n. The implementation principle is: each core can only run one thread at a time. Due to the different core types, the corresponding cores have different computing powers. When there are p threads running on p cores competing for the same mutex at the current moment, only threads running on cores with computing powers that have reached the threshold can leave the out-of-order waiting queue and join the contention queue. For example, if the computing powers of the corresponding cores of the n target threads all reach the threshold, the remaining pn threads will automatically become out-of-order waiters, waiting to join the contention queue to compete for the mutex. Specifically, the device determines n target threads based on p computing powers, where the p computing powers are the computing powers of the p cores running the p threads, one core runs one thread at the current moment, and the n target computing powers are all greater than the pn computing powers. The n target computing powers are the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers are the computing powers of the pn cores among the p cores excluding the n target cores.

[0235] Similarly, in an embodiment of the present application, the computing power of each core can also be reflected by the assigned score value, and the computing power is positively correlated with the score value. For example, the above-mentioned p computing powers can be reflected by the assigned p score values ​​(that is, they are scored according to their ability to execute critical sections). One way of assigning values ​​can be: the score ratio of different cores is the same as their computing power ratio. For example, in a large, medium, and small core asymmetric processor, if its computing power ratio is 3:2:1, then its score ratio is also set to 3:2:1, and the corresponding score values ​​can be assigned to 300, 200, 100, or 600, 400, 200. This application does not limit this. Accordingly, the implementation method for the device to determine n target threads based on p computing powers can be: first, determine n target score values ​​with values ​​greater than the score threshold from the p score values, and then determine the n threads corresponding to the n target score values ​​as the n target threads. That is, the thread with a score value greater than the preset score threshold is determined as the target thread.

[0236] It should be noted that in some embodiments of this application, the computing power of a core is related to its core type: the larger the core, the greater the computing power. It should be noted that in this embodiment of the application, cores of the same core type have the same computing power by default. Since this embodiment of the application determines n target threads from p threads based on computing power, there are at least two core types among the p cores mentioned above. Core types can include: large core, medium core, and small core.

[0237] It should also be noted that in some embodiments of the present application, it is also possible to select the appropriate type of core for priority based on the competition situation at runtime to achieve the highest throughput (i.e., dynamic out-of-order priority). Specifically, when the competition level of the mutex does not reach the preset condition, the score threshold is reduced according to the first preset gradient; conversely, when the competition level of the mutex reaches the preset condition, the score threshold is increased according to the second preset gradient. Among them, the preset condition is used to reflect whether the mutex is sufficiently competitive. The process of dynamic out-of-order priority described in this application can be found in the example description corresponding to Figure 9 above, and this application will not elaborate on this.

[0238] In the embodiment of the present application, the preset condition is used to reflect whether the mutual exclusion lock is sufficiently competitive. The specific situations that characterize whether the competition is sufficient can be found in the above-mentioned situations 1 to 5, and this application will not elaborate on this.

[0239] 1004. Determine, according to the out-of-order waiting queue, a contention queue in which n target threads compete for the mutex lock, so that the mutex lock is transferred based on the contention queue.

[0240] Finally, based on the out-of-order waiting queue, the contention queue of the n target threads competing for the mutex lock is determined, so that the mutex lock is transferred based on the contention queue. Specifically, since the out-of-order waiting queue is arranged according to the waiting time of the p threads, the n target threads selected from the p threads are still in the contention queue determined according to the waiting time.

[0241] To facilitate understanding of the process, the following is an example to illustrate. Suppose that at the current moment there are 5 threads (i.e., p=5) competing for the same mutex lock, namely thread a, thread b, thread c, thread d and thread e. Among them, according to the actual running delay and target delay requirements of each thread at the current moment, the waiting time of thread a is determined to be t1, the waiting time of thread b is t2, the waiting time of thread c is t3, the waiting time of thread d is t4, and the waiting time of thread e is t5. By comparison, assuming that t2>t4>t5>t1>t3, the queuing order of the out-of-order waiting queue is "thread b←thread d←thread e←thread a←thread c", where thread b is the head of the out-of-order waiting queue. Next, assume the device determines three target threads (n=3) based on the computing power of the five cores running the five threads: thread a, thread c, and thread d. Based on the positions of these three threads in the original out-of-order waiting queue, the order of the contention queue is determined to be "thread e ← thread a ← thread c." Finally, the mutex can be transferred based on this contention queue: "thread e ← thread a ← thread c."

[0242] To further understand the solution of the present application, the locking process and the releasing process of the mutual exclusion lock (ie, LGRF-AMP lock) of the present application are described in detail from the perspective of threads.

[0243] 1. The locking process of the mutex lock.

[0244] Please refer to Figure 11 for details. Figure 11 is a schematic diagram of a locking process of a mutex lock provided in an embodiment of the present application. The process may include the following steps:

[0245] 1101. Determine whether the score of the current core is greater than the score threshold of the mutex lock. If so, execute step 1106; if not, execute step 1102.

[0246] First, the target thread determines whether the score of the core where the target thread is currently located is greater than the score threshold of the mutex lock. If so, step 1106 is executed; if not, step 1102 is executed.

[0247] 1102. Record the current time.

[0248] The target thread records the current time as the start time.

[0249] 1103. Determine whether the current mutex lock is idle. If so, execute step 1105; if not, execute step 1104.

[0250] Afterwards, the target thread further determines whether the current mutex lock is idle. If so, the process moves to step 1105 ; if not, the process executes step 1104 .

[0251] 1104. Determine whether the out-of-order window set according to the application delay requirement has timed out. If so, execute step 1108; if not, return to execute step 1103.

[0252] The target thread continues to determine whether the out-of-order window set according to the application delay requirement has timed out. If so, the process jumps to step 1108 ; if not, the process returns to step 1103 .

[0253] 1105 . Reduce the score threshold of the mutex lock and jump to step 1108 .

[0254] The target thread lowers the score threshold of the mutex lock, thereby enabling more threads to compete for the mutex lock, and jumps to step 1108 .

[0255] 1106 . Determine whether the score threshold needs to be periodically updated and whether there are subsequent competitors. If so, execute step 1107 ; if not, execute step 1108 .

[0256] The target thread further determines whether the score threshold needs to be periodically updated (eg, determined by a random number) and whether there are subsequent competitors. If so, step 1107 is executed; if not, step 1108 is jumped to.

[0257] 1107 . Increase the score threshold of the mutex lock and jump to step 1108 .

[0258] The target thread increases the score threshold of the mutex lock, thereby reducing the contention for the mutex lock, and jumps to step 1108 .

[0259] 1108. Join the FIFO queue and obtain the mutex lock.

[0260] By calling the FIFO queue (a competitive queue implementation) and getting the mutex lock.

[0261] 2. The process of releasing the mutex lock.

[0262] Please refer to Figure 12 for details. Figure 12 is a schematic diagram of a lock release process of a mutex provided in an embodiment of the present application. The process may include the following steps:

[0263] 1201. Call the FIFO queue lock release process.

[0264] The target thread directly releases the mutex lock through the FIFO queue lock release process.

[0265] It should also be noted that, in some embodiments of the present application, the mutex lock's reordering adjustment module can also use a linear growth and exponential retreat strategy to adjust the reordering time window. Specifically, when the actual runtime latency exceeds the limit, it will directly halve the reordering window and update the unit of the next reordering window growth. Otherwise, it will slowly increase the size of the reordering window.

[0266] In summary, for a multi-level AMP system, this application proposes a novel dynamic out-of-order priority technology, which can select the appropriate type of core for priority according to the competition situation at runtime to achieve the highest throughput.

[0267] It should be noted that in some embodiments of the present application, if the n target threads are running on at least two NUMA nodes, this situation actually corresponds to the situation where the LGRF is connected to a heterogeneous many-core system (i.e., a system with multi-level AMP and NUMA characteristics). In this case, the mutex is actually a NUMA-aware lock, and the disorder level of the mutex is the global disorder level of the NUMA-aware lock (i.e., the disorder level of the global mutex). After determining the competition queue of the n target threads competing for the mutex based on the disordered waiting queue, the method may further include the following steps:

[0268] Step 1: Determine n out-of-order requirements of n target threads based on n actual runtime delays and n target delay requirements. The out-of-order requirements are used to characterize the urgency with which the target threads need to hold a global mutex lock.

[0269] Afterwards, the device further determines n out-of-order requirements of the n target threads based on the obtained n actual runtime delays and n target delay requirements, wherein one target thread corresponds to one out-of-order requirement, and the out-of-order requirement is used to characterize the urgency of the target thread's need to hold the global mutex lock.

[0270] Similarly, in some embodiments of the present application, the out-of-order requirement can be characterized by an upper limit on the number of transfers each time the global mutex lock required by the target thread is held.

[0271] Similarly, in some embodiments of the present application, a thread may be selected from p threads as a first thread. Assuming that the first thread includes m (m ≥ 1) code snippets with latency requirements, this code snippet may be referred to as a first code snippet. At the current moment, the first actual runtime latency and first target latency requirement of the first code snippet currently being executed by the first thread are obtained. Then, using each of the p threads as the first thread, the above steps are repeated until the p first actual runtime latencies and p first target latency requirements of the p first code snippets currently being executed by each of the p threads are obtained.

[0272] It should be noted that step 1 is similar to step 402 corresponding to FIG. 4 . Please refer to step 402 for details and will not be described in detail here.

[0273] Step 2: Determine the disorder degree of the global mutex lock according to the n disorder requirements, so that the global mutex lock is transferred based on the disorder degree. The disorder degree is used to represent the transfer number threshold each time the global mutex lock is held.

[0274] Finally, the device determines the disorder degree of the global mutex lock based on the n disorder requirements obtained, so that the global mutex lock is transferred based on the disorder degree, wherein the disorder degree is used to characterize the threshold of the number of transfers each time the global mutex lock is held. In addition, it should be noted that threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path, so that the critical sections of the NUMA local lock competitors can be batched, which can effectively avoid the frequent cache consistency overhead across NUMA nodes.

[0275] Similarly, in an embodiment of the present application, there may be different implementation methods for determining the degree of disorder of the global mutex lock based on n disorder requirements. For details, please refer to the implementation method for determining the degree of disorder of the global mutex lock based on n disorder requirements in the above step 403, which will not be described in detail in this application.

[0276] It should be noted that step 2 is similar to step 403 corresponding to FIG. 4 . Please refer to step 403 for details and will not be described in detail here.

[0277] It should be noted that in the embodiments of the present application, for the case where LGRF is connected to a heterogeneous multi-core system (i.e., there are multi-level AMP and NUMA characteristics at the same time), the controllable out-of-order lock can be called an LGRF-HETE lock. The present application can also further implement hierarchical out-of-order management. The LGRF-HETE lock can organically combine multi-layer out-of-order strategies based on the hardware characteristics of the heterogeneous multi-core to optimize the throughput for different hardware characteristics, and adjust the degree of out-of-order at different levels based on the runtime competition situation. In order to efficiently manage multiple out-of-orders, different out-of-order strategies can be divided according to whether they have strict requirements for the lock transfer order: those with strict requirements need to be placed in the inner layer, and their needs determine the final transfer order; those without strict requirements can be placed in the outer layer, and they can affect the throughput through long-term transfer characteristics.

[0278] Specifically, in heterogeneous many-core systems, NUMA-aware out-of-order strategies have strict requirements on the order of lock transfers. They must place competitors from the same NUMA node in adjacent positions to effectively avoid cross-node cache consistency overhead. Therefore, NUMA-aware out-of-order strategies must be placed in the inner layer. Multi-level AMP-aware out-of-order strategies, on the other hand, do not have strict requirements on the order of lock transfers. They only need to increase the proportion of cores with faster processing performance on the critical path to improve throughput. Therefore, multi-level AMP-aware out-of-order strategies can be placed in the outer layer.

[0279] For ease of understanding, the following describes the hierarchical out-of-order management using a specific example. Please refer to Figure 13 for details, which illustrates an example hierarchical out-of-order management provided by an embodiment of the present application. In Figure 13, different shapes represent lock contenders of different core types, while different padding represents different NUMA nodes. When different contenders attempt to hold the controllable out-of-order lock, the outer multi-level AMP-aware out-of-order strategy first selects suitable contenders based on the current contention level. Since there are fewer large cores at this point, they cannot fully compete for the controllable out-of-order lock. Therefore, the multi-level asymmetric multi-core-aware out-of-order strategy prioritizes both large and medium cores, forcing small cores to become out-of-order waiters. For prioritized contenders, the inner NUMA-aware out-of-order strategy re-out-orders them. It arranges these lock contenders according to their NUMA nodes, thereby avoiding cross-node caching overhead. Furthermore, embodiments of the present application also require coordinating the degree of out-of-order at different levels based on the latency requirements of the application. When adjusting the out-of-order level, a single principle applies: only adjust the out-of-order level at the level most relevant to the current latency performance. Specifically, if the current competitor has weak processing performance and is therefore identified as an out-of-order waiter in multi-level asymmetric out-of-order (such as thread-1 in Figure 13), it will first adjust the out-of-order window size to control the out-of-order in the asymmetric multi-core strategy. This is because the out-of-order window size directly affects the final latency performance. Only when the out-of-order window has grown to its maximum value or is already 0 will the inner layer's out-of-order degree be further adjusted. If the current competitor is already in the ranks of prioritized competitors in the asymmetric multi-core out-of-order (such as thread-2 in Figure 13), it will directly adjust the NUMA out-of-order degree to meet the latency requirements.

[0280] Similarly, to further understand the solution of the present application, the locking process and the releasing process of the out-of-order controllable lock (ie, LGRF-HETE lock) of the present application will be described in detail from the perspective of threads.

[0281] 1. Locking process of LGRF-HETE lock.

[0282] Please refer to Figure 14 for details. Figure 14 is a schematic diagram of a locking process of the LGRF-HETE lock provided in an embodiment of the present application. The process may include the following steps:

[0283] 1401. Determine whether the score of the current core is greater than the lock score threshold. If so, execute step 1406; if not, execute step 1402.

[0284] First, the target thread determines whether the score of the core where the target thread is currently located is greater than the lock score threshold. If so, step 1406 is executed; if not, step 1402 is executed.

[0285] 1402. Record the current time and mark that the current epoch of the current thread is blocked in AMP disorder.

[0286] The target thread records the current time as the start time and marks that the current epoch of the current thread is blocked in the AMP disorder, which will be used later when adjusting the disorder degree.

[0287] 1403. Determine whether the current lock is idle. If so, execute step 1405; if not, execute step 1404.

[0288] Afterwards, the target thread further determines whether the current lock is idle. If so, the process moves to step 1405 ; if not, the process executes step 1404 .

[0289] 1404. Determine whether the out-of-order window set according to the application delay requirement has timed out. If so, execute step 1408; if not, return to execute step 1403.

[0290] The target thread continues to determine whether the out-of-order window set according to the application delay requirement has timed out. If so, the process jumps to step 1408 ; if not, the process returns to step 1403 .

[0291] 1405 . Reduce the lock score threshold and jump to step 1408 .

[0292] The target thread lowers the lock score threshold, thereby enabling more threads to compete for the lock, and jumps to step 1408 .

[0293] 1406 . Determine whether the score threshold needs to be periodically updated and whether there are subsequent competitors. If so, execute step 1407 ; if not, execute step 1408 .

[0294] The target thread further determines whether the score threshold needs to be periodically updated (eg, determined by a random number) and whether there are subsequent competitors. If so, step 1407 is executed; if not, step 1408 is jumped to.

[0295] 1407 . Increase the lock score threshold and jump to step 1408 .

[0296] The target thread increases the lock score threshold to reduce lock contention, and jumps to step 1408 .

[0297] 1408. Call the locking process of the NUMA-aware lock.

[0298] Finally, the lock is acquired by calling the locking interface of the NUMA-aware lock. For details, please refer to steps 701 to 709 corresponding to Figure 7 above, and this application will not elaborate on this.

[0299] 2. The unlocking process of LGRF-HETE lock.

[0300] Please refer to Figure 15 for details. Figure 15 is a schematic diagram of a lock release process of the LGRF-HETE lock provided in an embodiment of the present application. The process may include the following steps:

[0301] 1501. Call the NUMA-aware lock release process.

[0302] The target thread only needs to call the lock release interface of the underlying NUMA-aware lock. For details, please refer to steps 801 to 806 corresponding to Figure 8 above, and this application will not go into details.

[0303] It should be noted that in the embodiment of the present application, the disorder adjustment module of the LGRF-HETE lock is relatively complex. In addition to recording the NUMA disorder requirements and the multi-level AMP disorder requirements, it also records whether it is currently blocked by the outer AMP disorder, thereby adjusting the disorder level of the level most relevant to the current latency performance. Whenever an epoch starts, it will not be blocked by the outer AMP disorder by default. Once the outer AMP disorder policy blocks the competitor in any lock in the epoch, the flag will be updated (i.e., step 1402 in Figure 14). For competitors that are not blocked by the outer AMP disorder policy, their latency performance is directly related to the NUMA-perceived disorder level of the inner layer. Therefore, it directly adjusts the NUMA disorder level at the end of the epoch. For competitors that are blocked by the outer AMP disorder policy, their latency performance is directly related to the outer AMP-perceived disorder level, so it should adjust the AMP disorder level at the end of the epoch. In addition, when the latency SLO requirement is so loose that the disorder level of the outer AMPs has been set to the highest, or when the latency SLO is so tight that disorder of the outer AMPs is no longer allowed, the disorder level of the inner NUMA will be adjusted instead.

[0304] Please refer to FIG. 16 for details. FIG. 16 is a flow chart of increasing the degree of disorder in the disorder adjustment module in the LGRF-HETE lock according to an embodiment of the present application. The flow chart may include the following steps:

[0305] 1601. Whether there is AMP out of order and blocked in the epoch, if yes, execute step 1602; if no, execute step 1604.

[0306] First, determine whether the current epoch is blocked in AMP out of order. If so, execute step 1602; if not, execute step 1604.

[0307] 1602. Has the AMP disorder level reached the maximum? If so, execute step 1604; if not, execute step 1603.

[0308] Then determine whether the AMP disorder level is the maximum, for example, determine whether the disorder window is greater than a fixed threshold. If so, execute step 1604 (because the AMP disorder level cannot be adjusted at this time); if not, execute step 1603.

[0309] 1603. Increase the disorder degree of multi-stage AMP.

[0310] Using a method similar to the LGRF-AMP lock, the disorder degree of the multi-stage AMP is increased.

[0311] 1604. Increase the disorder degree of NUMA disorder.

[0312] Use a similar method to the LGRF-NUMA lock to increase the degree of NUMA disorder.

[0313] FIG17 is a flow chart showing a method for reducing the degree of disorder in the disorder adjustment module of the LGRF-HETE lock according to an embodiment of the present application. The flow chart may include the following steps:

[0314] 1701. Whether there is AMP out of order and blocked in the epoch, if so, execute step 1702; if not, execute step 1704.

[0315] First, determine whether the current epoch is blocked in AMP disorder. If so, execute step 1702; if not, execute step 1704.

[0316] 1702. Whether the AMP disorder degree has been minimized, if so, execute step 1704; if not, execute step 1703.

[0317] Then determine whether the AMP disorder level is minimum, for example, determine whether the disorder window is 0. If so, execute step 1704 (because the AMP disorder level cannot be adjusted at this time); if not, execute step 1703.

[0318] 1703. Reduce the disorder degree of multi-stage AMP.

[0319] A method similar to the LGRF-AMP lock is used to reduce the disorder of multi-stage AMPs.

[0320] 1704. Reduce the disorder degree of NUMA disorder.

[0321] Use a method similar to LGRF-NUMA lock to reduce the degree of NUMA disorder.

[0322] In order to have a more intuitive understanding of the beneficial effects brought about by the embodiments of the present application, the technical effects brought about by the embodiments of the present application are further compared below.

[0323] A,Beneficial effects of LGRF access to NUMA systems.

[0324] This scenario A verifies the performance of LGRF in the NUMA system. Specifically, this application is carried out on an experimental platform with two Intel Xeon processors 6330 (i.e., 2 NUMA nodes), and different configurations are performed according to different test objects. In the NUMA system test, all tests will use all 2 NUMA nodes, and each NUMA node has 14 processor cores. All cores run at a frequency of up to 3GHz. Integrating LGRF into existing software only requires the simplest modifications. The implementation of this application includes several micro-benchmark tests and database application tests. In database applications, accessing LGRF only requires marking the code snippets with latency requirements and including the header file of LGRF.

[0325] First, we demonstrate the performance of LGRF-NUMA (abbreviated as LGRF in this section) in a microbenchmark. In this microbenchmark, 28 threads are created, each bound to a different core in two NUMA nodes. These threads repeatedly acquire the same mutex and access and modify a shared cache line within a critical section. The code segment holding the lock and executing the critical section is considered an epoch and wrapped with the corresponding LGRF interface. Figure 18(a) shows the performance of existing NUMA-aware locks and LGRF locks. This comparison is performed with existing NUMA-aware mutexes, including the HMCS lock and the SHFL lock, and the widely used non-NUMA-aware lock, the MCS lock. The out-of-orderness (i.e., the upper threshold for local transfers) of the NUMA-aware locks is statically set to the same value. The LGRF suffix in Figure 18(a) represents the set SLO (in microseconds), while MAX represents no limit. The horizontal axis in Figure 18(a) represents different mutexes, the left vertical axis represents the latency to execute a critical section while holding the lock, and the right vertical axis represents the average throughput per second. As shown in Figure 18 (a), when the SLO is set to 0, LGRF does not allow out-of-order locks, resulting in performance similar to that of the MCS lock. When the SLO is set to 100 μs, the tail latency of LGRF is also 100 μs. At this point, the tail latency of LGRF is only one-fourth that of the HMCS lock, while the throughput is 10% higher. With further relaxation of the SLO (LGRF-MAX), the throughput of LGRF is 14% higher than that of the HMCS lock.

[0326] Figure 18(b) further illustrates the latency and throughput of LGRF under different SLO settings. In Figure 18(b), the horizontal axis represents different SLO settings, the left vertical axis represents the critical section execution latency, and the right vertical axis represents the average throughput. As shown in Figure 18(b), when the SLO setting is very low (e.g., less than 20μs), LGRF cannot meet its SLO even without out-of-order locks. In this case, LGRF directly uses FIFO ordering to ensure the lowest acquisition latency. As the SLO gradually increases, LGRF gradually begins to tolerate higher levels of out-of-order locks. At this point, the tail latency closely follows the Y = X line, indicating that the current latency is consistent with the set SLO and no latency violations occur. LGRF's throughput also steadily increases as the SLO is relaxed. Furthermore, when LGRF and HMCS have the same throughput (SLO of 20μs), the lock acquisition tail latency is reduced by 95% compared to HMCS. Therefore, the global out-of-order on-demand alignment technology in LGRF-NUMA can effectively control the global out-of-order degree of NUMA-aware locks according to the out-of-order requirements of all competitors, so that the coarse-grained latency requirements of the application are met.

[0327] In addition, this application further tests the performance of LGRF in two commercial databases. LevelDB and KyotoCabinet databases were selected for testing. The LevelDB test uses its own Randomread test set, which will continuously read information randomly from the key-value database. The KyotoCabinet test uses its own kccachetest test set, which will perform read and write operations on a cache database. In order to quantify the throughput, the test is modified here so that it outputs the number of operations within a given time as the throughput. The test puts one operation of the database into an epoch and marks its latency SLO.

[0328] Figures 19(a) and 19(c) compare the performance of LGRF with existing mutex locks. The figures are consistent with those in the microbenchmark. As can be seen from these two figures, when the SLO is set to 0 in LGRF, LGRF performs similarly to MCS. When there is no SLO constraint, LGRF maximizes out-of-order locks, achieving throughput similar to HMCS. In this case, the acquisition latency of both LGRF and HMCS locks is hundreds of times higher than that of MCS, potentially causing application latency to exceed limits. Unlike existing NUMA-aware locks, LGRF can adaptively reduce some out-of-order locks to meet latency SLO requirements, while maximizing throughput. Figures 19(b) and 19(d) show the performance with different SLO settings. Similar to the microbenchmark results, as the SLO is relaxed, LGRF improves throughput while maintaining strict SLO latency. In LevelDB, when the SLO is relaxed to 100μs, its throughput is comparable to HMC. At this time, its tail latency is only 1 / 3 of that of the HMCS lock.

[0329] In summary, the out-of-order level of existing NUMA-aware locks is statically assigned. This static out-of-order level results in significant lock acquisition latency that is uncontrollable as contention levels change. Furthermore, the corresponding throughput performance is unpredictable. Applications struggle to select the appropriate out-of-order level based on their specific latency requirements. In contrast, the LGRF lock collects application coarse-grained latency requirements through a simple interface and leverages global out-of-order on-demand alignment technology at runtime. This automatically selects the appropriate out-of-order level to maximize throughput while strictly meeting the varying latency requirements of applications.

[0330] B. Beneficial effects of LGRF access to a multi-stage AMP system.

[0331] This scenario B verifies the performance of LGRF in a multi-level AMP system. Specifically, this application simulates a multi-level AMP system containing large, medium and small cores, with frequencies of 3GHz, 2GHz and 1GHz respectively, by utilizing the per-core frequency modulation capability of Intel processors. In order to simulate the asymmetric number of different types of cores in a real multi-level AMP system, the large, medium and small cores are set to 2, 4 and 8 respectively, and these 14 cores are all in the same NUMA node. The implementation of this application includes several micro-benchmark tests and database application tests. In database applications, accessing LGRF only requires marking the code snippets with latency requirements and including the header file of LGRF.

[0332] First, we tested the dynamic out-of-order priority technology in the LGRF-AMP lock (LGRF for short) to verify its effectiveness in dynamically determining out-of-order priority based on varying contention scenarios. Figure 20 shows the throughput performance of the LGRF lock under varying levels of contention (the lines formed by the equilateral triangles in Figure 20). Specifically, the test created 14 threads bound to different cores and adjusted the contention level by adjusting the number of no-operation (NOP) instructions between lock acquisitions. The horizontal axis in Figure 20 represents the number of NOP instructions between lock acquisitions; a larger value indicates lower contention. The vertical axis in Figure 20 represents the throughput of different mutex locks under varying levels of contention. This comparison primarily compares the MCS lock, which allows all contenders to acquire the mutex in first-come, first-served order, and the LibASL lock, which prioritizes large cores with a fixed priority (LibASL(B) in Figure 20). Furthermore, a simple modification was made to the LibASL lock to statically prioritize large and medium cores (LibASL(B+M) in Figure 20). To demonstrate the optimal performance of different strategies, neither LibASL nor LGRF sets a latency SLO. Therefore, both mutexes can maximize out-of-order performance while preventing starvation. As shown in Figure 20, under varying levels of contention, LGRF can dynamically adjust priorities to optimize throughput for that level of contention. When contention is high, LGRF achieves a throughput similar to LibASL (B) by prioritizing only large cores. As contention decreases, prioritizing only large cores fails to achieve optimal throughput, so LGRF prioritizes both large and medium cores, achieving a throughput similar to LibASL (B+M). When contention is sufficiently low, MCS achieves the optimal throughput. At this point, LGRF assigns equal priority to all cores, achieving throughput performance close to that of MCS.

[0333] Figure 21(a) further illustrates LGRF's latency and throughput performance in a microbenchmark. This test creates 14 threads bound to different cores and repeatedly acquires the same mutex. At the contention level encountered in this microbenchmark, even without any latency requirements, LibASL's throughput is only comparable to MCS (with no advantage). This is because LibASL prioritizes only large cores, which, at this contention level, cannot fully compete for the mutex (similar to the critical section interval of 500 NOP instructions in Figure 20). Furthermore, because LibASL prioritizes only large cores, the tail latency of medium and small cores (the grid and shaded columns in Figure 21(a)) is significantly affected. Consequently, LGRF is able to dynamically prioritize appropriate cores while meeting latency requirements, achieving better throughput than LibASL. As shown in Figure 21(a), when the latency requirement is set to 0, LGRF falls back to a FIFO strategy and achieves the same lock performance as MCS. When the latency SLO requirement is relaxed to 10μs, LGRF achieves a 44% higher throughput than LibASL (30% higher than MCS lock), which has no latency requirement. In this case, LGRF prioritizes large and medium cores, resulting in lower tail latency for these cores and a tail latency improvement for small cores that meets the SLO requirement. Further relaxing the SLO requirement, LGRF's throughput improvement over LibASL increases to 54% (40% higher than MCS lock). Figures 21(b) and 21(c), respectively, show the performance of LGRF and LibASL under different SLO settings on this microbenchmark. The horizontal axis represents the set SLO, the left vertical axis represents latency, and the right vertical axis represents throughput. As can be seen from the figure, as the SLO requirement is relaxed for LGRF, the latency of small cores closely follows the Y=X line. This indicates that LGRF, while ensuring latency, maximizes the ordering of medium and large cores before small cores, thereby improving throughput. Therefore, throughput performance improves as the SLO increases. Conversely, while LibASL can ensure latency meets the SLO (i.e., closely adheres to the Y=X line), it prioritizes only large cores, so throughput cannot be effectively improved. As the SLO increases, throughput only improves slightly. Even when the SLO increases to a certain level, throughput decreases to a certain extent because large cores cannot fully compete for mutexes. LGRF achieves significant throughput improvements over LibASL under all SLO settings.

[0334] In addition, this application also uses the same database tests as the above-mentioned Scenario A embodiment to test the performance of LGRF in a multi-level AMP system. In these database tests, this application creates 14 threads bound to different cores. Figure 22 shows the test results, with the same legend as in the above-mentioned Scenario A embodiment. As shown in Figure 22 (a), in the LevelDB test, LibASL, which prioritizes only large cores, suffers from throughput issues. Even without any latency requirements, its throughput is even lower than that of MCS locks, which pass mutexes in a first-come, first-served order. In this scenario, LGRF can dynamically prioritize large and medium cores based on the level of competition, achieving higher throughput. When the SLO is set to 30μs, LGRF prioritizes large and medium cores while ensuring that the tail latency of small cores meets the standard (i.e., the pure shaded columns in Figure 22 (a) do not exceed the 30μs scale), resulting in a throughput 33% higher than that of LibASL, which has no latency requirements. Figure 22 (b) further illustrates the performance of LGRF under different SLO settings. Similar to the microbenchmark, LGRF maximizes out-of-order processing to improve throughput while strictly ensuring that tail latencies for all core types adhere to the SLO (i.e., below the Y = X line). The results of the KyotoCabinet test differ somewhat from those of LevelDB. In the KyotoCabinet test, due to higher contention, LibASL, which prioritizes only large cores, achieves significant throughput improvements. The throughput of LGRF, which has no latency requirements (i.e., LGRF-MAX in Figure 22(c)), is similar to that of LibASL. The difference is that LGRF prioritizes medium cores to a certain extent, resulting in significantly lower tail latencies for medium cores than for small cores. This is because competition for large cores is insufficient, so LGRF's dynamic prioritization allows some medium cores to participate. However, the number of these medium cores is relatively small, resulting in a throughput close to that of LibASL. Figure 22(d) further confirms this phenomenon. As shown in Figure 22(d), as the SLO is relaxed, the tail latency of medium cores also increases to a certain extent, but remains somewhat below the Y = X line. This means that although LGRF also prioritizes medium cores to a certain extent, the critical path is still mainly executed on large cores, so the throughput is similar to LibASL.

[0335] In summary, because there's no statically optimal out-of-order strategy in multi-level AMP systems, LibASL's strategy of prioritizing only large cores cannot be extended to multi-level AMP systems. LGRF's dynamic out-of-order priority technology dynamically adjusts out-of-order priorities based on the level of contention at runtime to optimize throughput. When contention is high (as in the KyotoCabinet test), LGRF achieves the same performance as LibASL. As contention decreases, LGRF dynamically adjusts priorities, significantly surpassing the throughput of LibASL and existing scalable mutexes while maintaining latency.

[0336] C. The beneficial effects of LGRF access to heterogeneous many-core (i.e., multi-level AMP and NUMA features coexisting) systems.

[0337] This scenario C verifies the performance of LGRF in a heterogeneous many-core system. Specifically, in the heterogeneous many-core test, the implementation of this application also uses per-core frequency modulation to simulate the multi-level AMP characteristics. Specifically, in the two NUMA nodes of the test platform (the same implementation method as in scenario A), the implementation of this application adopts the same configuration as in the multi-level AMP system in scenario B, that is, 2 large cores, 4 medium cores and 8 small cores are set, and they run at frequencies of 3GHz, 2GHz and 1GHz respectively. Therefore, the whole system has a total of 4 large cores, 8 medium cores and 16 small cores. Similar to the previous implementation, the implementation of this application includes several micro-benchmark tests and database application tests. In database applications, accessing LGRF only requires marking the code snippets with latency requirements and including the header file of LGRF.

[0338] First, a series of microbenchmarks demonstrate the performance of LGRF-HETE (LGRF). Figure 23 illustrates the throughput scalability of LGRF. The horizontal axis in Figure 23 represents the number of threads repeatedly contending for the same mutex, while the vertical axis represents the average critical section execution throughput. These threads are bound to different cores, with the first 14 cores forming the first NUMA node, distributed in the order of large cores, medium cores, and small cores. Furthermore, to demonstrate the ideal performance ceiling for different strategies, LGRF does not impose latency requirements. As shown in Figure 23, existing scalable mutex locks, including the Syncord lock, which simply fuses LibASL with NUMA-aware locks, do not exhibit good performance scalability. However, LGRF does not experience a scalability cliff: after the large and medium cores of the first NUMA node compete and reach peak throughput, further additions to the lock contender do not cause a throughput drop. This is because LGRF minimizes cross-NUMA memory accesses on the critical path while prioritizing large and medium cores on the same NUMA node to achieve optimal throughput. Accordingly, because Syncord prioritizes only large cores, it cannot scale to medium cores in the first NUMA node (i.e., throughput does not increase when the number of cores exceeds 2). It can only utilize the large cores in the second NUMA node. Therefore, LGRF achieves approximately 30% higher throughput than Syncord at 28 cores.

[0339] Figure 24(a) further illustrates the latency and throughput performance of different mutex locks at 28 threads, similar to the previous section. As shown in Figure 24(a), NUMA-aware locks, including HMCS and SHFL locks, achieve significantly higher throughput than the non-NUMA-aware MCS lock. However, due to their use of a NUMA-aware out-of-order strategy, their latency is significantly higher than that of the MCS lock. Although Syncord prioritizes large cores, this alone, given the current level of contention, cannot fully compete for mutex locks, resulting in very limited throughput improvements. LGRF, on the other hand, uses dynamic out-of-order prioritization technology to prioritize both large and medium cores in two nodes (they have similar and very low latency) based on contention levels, achieving higher throughput. When the SLO is set to 300μs, LGRF's throughput exceeds Syncord's by 26%. Furthermore, compared to the NUMA-aware HMCS lock, LGRF achieves a 28% throughput improvement while maintaining only one-third the tail latency. This is because LGRF can more efficiently utilize the relaxed latency, applying it to appropriate out-of-order (including NUMA and multi-level AMP out-of-order), thereby maximizing throughput. Figures 24(b) and 24(c), respectively, show the latency and throughput performance of LGRF and Syncord for different SLO settings on this microbenchmark. As can be seen, because Syncord uses a NUMA-aware lock with fixed out-of-order functionality at the underlying layer, it cannot meet the SLO requirement when the SLO is less than 400μs. In this case, Syncord's throughput can only be maintained consistent with the underlying NUMA-aware lock. In contrast, LGRF can coordinate different out-of-order policies while meeting the SLO, making more appropriate out-of-order decisions and achieving higher throughput. Specifically, LGRF prioritizes out-of-order on large cores rather than on NUMA-local nodes. Therefore, when the SLO is 120μs, LGRF is able to meet the latency requirement (75% lower than Syncord) while achieving a 23% higher throughput. Syncord only allows out-of-order processing of large and small cores when the SLO is sufficiently high. However, due to the high contention in this scenario, Syncord's improvement in out-of-order processing of only large cores is minimal. When the SLO is 600μs, LGRF prioritizes both medium and large cores, resulting in a 22% higher throughput than Syncord.

[0340] In addition, the implementation of this application also uses the same database test as the above-mentioned Case A and Case B to test the performance of LGRF in a heterogeneous multi-core system. Figure 25 (a) and Figure 25 (c) show the test results. In the LevelDB Randomread test, the throughput of Syncord without latency constraints is actually worse than that of HMCS. This is because only prioritizing large cores cannot fully compete for mutex locks. Correspondingly, in the same test set, the throughput of LGRF without latency constraints is 37% higher than that of Syncord. In the KyotoCabinet test, Synccord has a throughput 12% higher than that of HMCS. However, Syncord still has room for improvement: LGRF can further improve the throughput, which is 14% higher than Syncord in the same test. Figure 25 (b) and Figure 25 (d) further demonstrate the performance of LGRF when different latency SLO requirements are set in the two database test sets. As can be seen, when the SLO latency requirement is set lower than the MCS latency (e.g., the MCS latency in LevelDB is 50μs), the latency requirement cannot be met even if the lock is transferred in a first-come, first-served order. At this point, LGRF falls back to the FIFO strategy and behaves the same as MCS locks. As the SLO requirement is gradually relaxed, LGRF can effectively coordinate the two layers of out-of-order, while ensuring that the latency requirement is met (i.e., lower than Y=X) while maximizing out-of-order to improve throughput.

[0341] In summary, due to the asymmetric computing power and inconsistent memory access characteristics of heterogeneous many-core systems, existing scalable locks cannot achieve good performance scalability in heterogeneous many-core systems. Compared to NUMA-aware and AMP-aware locks, LGRF can take into account both hardware characteristics to formulate appropriate out-of-order strategies, thereby significantly improving throughput. Compared to the previously proposed Syncord, also designed for heterogeneous many-core systems, LGRF can more precisely control different out-of-order strategies to meet latency requirements, while also improving throughput through dynamic out-of-order technology.

[0342] On the basis of the above corresponding embodiments, in order to better implement the above scheme of the embodiment of the present application, the following also provides relevant devices for implementing the above scheme. Please refer to Figure 26 specifically, which is a structural diagram of the device provided by the embodiment of the present application. The device 2600 is applied to a computer device, and the computer device includes at least two NUMA nodes. The device 2600 includes: an acquisition module 2601, a first determination module 2602, and a second determination module 2603, wherein the acquisition module 2601 acquires n actual running delays and n target delay requirements of n target threads, one target thread corresponds to one actual running delay and one target delay requirement, and the n target threads are threads competing for the same global mutex at the current moment, and the n target threads run on at least two NUMA nodes. MA node, n≥2; the first determination module 2602 determines the n out-of-order requirements of the n target threads based on the n actual runtime delays and the n target delay requirements, where one target thread corresponds to one out-of-order requirement, and the out-of-order requirement is used to characterize the urgency with which the target thread needs to hold the global mutex lock; the second determination module 2603 determines the out-of-order degree of the global mutex lock based on the n out-of-order requirements, so that the global mutex lock is transferred based on the out-of-order degree, and the out-of-order degree is used to characterize the threshold number of transfers each time the global mutex lock is held, and threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path.

[0343] In one possible design, the second determination module 2603 is specifically used to: update the disorder degree of the global mutex lock in real time during the transfer process of the global mutex lock according to the disorder requirement of the target thread on the lock transfer path, so that the global mutex lock is transferred based on the real-time updated disorder degree.

[0344] In one possible design, the second determination module 2603 is further specifically used to: when the disorder degree has not been updated for more than a preset period of time, increase the value of the disorder degree according to a target preset gradient.

[0345] In one possible design, the out-of-order requirement includes an upper limit on the number of transfers required by the target thread each time the global mutex lock is held.

[0346] In one possible design, the first thread is one of the n target threads, and the first thread includes m first code snippets with delay requirements, where m≥1. The acquisition module 2601 is specifically used to: obtain the first actual runtime delay and the first target latency requirement of the first code snippet currently being run by the first thread; and repeat the above steps with each of the n target threads as the first thread until n first actual runtime delays and n first target latency requirements of the n first code snippets currently being run by each of the n target threads are obtained.

[0347] In one possible design, the acquisition module 2601 is further used to: before obtaining the n actual running delays and n target delay requirements of the n target threads, determine the n target threads from p threads, where the p threads are threads competing for the same global mutex lock at the current moment, and p≥n.

[0348] In one possible design, the acquisition module 2601 is further specifically used to: determine the n target threads based on p computing powers, where the p computing powers are the computing powers of the p cores running the p threads, one core runs one thread at the current moment, and the n target computing powers are all greater than pn computing powers. The n target computing powers are the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers are the computing powers of the pn cores in the p cores excluding the n target cores.

[0349] In one possible design, the computing power of the p computing powers is reflected by the p assigned score values, and the computing power is positively correlated with the score value. The acquisition module 2601 is further specifically used to: determine n target score values ​​greater than the score threshold from the p score values, and determine that the n threads corresponding to the n target score values ​​are the n target threads.

[0350] In one possible design, the apparatus 2600 further includes an adjustment module 2604. The adjustment module 2604 is configured to reduce the score threshold according to a first preset gradient if the contention level of the global mutex does not meet a preset condition, where the preset condition is used to reflect whether the contention level of the global mutex is sufficient.

[0351] In one possible design, the apparatus 2600 further includes an adjustment module 2604. The adjustment module 2604 is configured to increase the score threshold according to a second preset gradient when the contention level of the global mutex lock reaches a preset condition, wherein the preset condition is used to reflect whether the contention level of the global mutex lock is sufficient.

[0352] In one possible design, the computing power is related to the core type of the core.

[0353] In a possible design, the p cores include at least two core types.

[0354] In one possible design, the core type includes at least: a large core, a medium core, or a small core.

[0355] In a possible design, the p threads form a waiting queue, and the acquisition module 2601 is further configured to determine the n target threads from the p threads based on a FIFO principle.

[0356] It should be noted that the information interaction, execution process, etc. between the modules / units in the device 2600 are based on the same concept as the above-mentioned method embodiment in this application. For specific contents, please refer to the description in the method embodiment shown above in this application, and will not be repeated here.

[0357] The embodiment of the present application also provides a device, please refer to Figure 27 for details, Figure 27 is a structural diagram of the device provided by the embodiment of the present application, the device 2700 is applied to a computer device, the processor of the computer device includes at least p cores, p ≥ 2, the device 2700 includes: an acquisition module 2701, a first determination module 2702, a second determination module 2703, and a third determination module 2704, wherein the acquisition module 2701 is used to obtain p actual runtime delays and p target latency requirements of p threads, one thread corresponds to one actual runtime delay and one target latency requirement, the p threads are threads competing for the same mutex at the current moment, the p threads run on p cores, one core runs one thread at the current moment, the There are at least two different computing power values ​​for the p computing powers of the p cores, p≥2; the first determination module 2702 is used to determine the out-of-order waiting queue for the p threads waiting to compete for the mutex lock based on the p actual runtime delays and the p target delay requirements; the second determination module 2703 is used to determine n target threads based on the p computing powers, the n target computing powers are all greater than pn computing powers, the n target computing powers are the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers are the computing powers of the pn cores in the p cores excluding the n target cores, p≥n; the third determination module 2704 is used to determine the competition queue for the n target threads to compete for the mutex lock based on the out-of-order waiting queue, so that the mutex lock is transferred based on the competition queue.

[0358] In one possible design, the computing power of the p computing powers is reflected by the p assigned score values, and the computing power is positively correlated with the score value. The second determination module 2703 is specifically used to: determine n target score values ​​greater than the score threshold from the p score values; and determine that the n threads corresponding to the n target score values ​​are the n target threads.

[0359] In one possible design, the device 2700 also includes an adjustment module 2705, which is used to reduce the score threshold according to a first preset gradient when the degree of competition for the mutex lock does not meet a preset condition. The preset condition is used to reflect whether the mutex lock is sufficiently competitive.

[0360] In one possible design, the device 2700 also includes an adjustment module 2705, which is used to increase the score threshold according to a second preset gradient when the degree of competition for the mutex lock reaches a preset condition. The preset condition is used to reflect whether the mutex lock is sufficiently competitive.

[0361] In one possible design, the computing power is related to the core type of the core.

[0362] In a possible design, the p cores include at least two core types.

[0363] In one possible design, the core type includes at least: a large core, a medium core, or a small core.

[0364] In one possible design, the n target threads run on at least two NUMA nodes, and the mutex lock includes a global mutex lock in a NUMA-aware lock. The third determination module 2704 is further used to: after determining the competition queue of the n target threads competing for the mutex lock based on the out-of-order waiting queue, determine n out-of-order requirements of the n target threads based on the n actual running delays and n target latency requirements of the n target threads, one out-of-order requirement corresponding to each target thread, and the out-of-order requirement is used to represent the urgency with which the target thread needs to hold the global mutex lock; determine the out-of-order degree of the global mutex lock based on the n out-of-order requirements, so that the global mutex lock is transferred based on the out-of-order degree, and the out-of-order degree is used to represent a threshold of the number of transfers each time the global mutex lock is held. Threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path.

[0365] In one possible design, the third determination module 2704 is specifically used to: update the disorder degree of the global mutex lock in real time during the transfer process of the global mutex lock according to the disorder requirement of the target thread on the lock transfer path, so that the global mutex lock is transferred based on the real-time updated disorder degree.

[0366] In one possible design, the third determination module 2704 is further specifically used to: when the disorder degree exceeds a preset time period without being updated, increase the value of the disorder degree according to a target preset gradient.

[0367] In one possible design, the out-of-order requirement includes an upper limit on the number of transfers required by the target thread each time the global mutex lock is held.

[0368] In one possible design, the first thread is one of the p threads, and the first thread includes m first code snippets with delay requirements, where m≥1. The acquisition module 2701 is specifically used to: obtain the first actual runtime delay and the first target latency requirement of the first code snippet currently being run by the first thread; and repeat the above steps with each of the p threads as the first thread until p first actual runtime delays and p first target latency requirements of the p first code snippets currently being run by each of the p threads are obtained.

[0369] It should be noted that the information interaction, execution process, etc. between the modules / units in the device 2700 are based on the same concept as the above-mentioned method embodiments in this application. For specific contents, please refer to the description in the method embodiments shown above in this application, and will not be repeated here.

[0370] Next, a computer device provided by an embodiment of the present application is introduced. Please refer to Figure 28. Figure 28 is a structural diagram of a computer device provided by an embodiment of the present application. The device 2600 described in the embodiment corresponding to Figure 26 can be deployed on the computer device 2800 to implement the functions of the device 2600 in the embodiment corresponding to Figure 26. The device 2700 described in the embodiment corresponding to Figure 27 can also be deployed on the computer device 2800 to implement the functions of the device 2700 in the embodiment corresponding to Figure 27. Specifically, the computer device 2800 is implemented by one or more servers. The computer device 2800 may have relatively large differences due to different configurations or performances. It may include one or more central processing units (CPUs) 2822 and memories 2832, and one or more storage media 2830 (for example, one or more mass storage devices) for storing application programs 2842 or data 2844. Among them, the memory 2832 and the storage medium 2830 can be temporary storage or persistent storage. The program stored in the storage medium 2830 may include one or more modules (not shown), each of which may include a series of instruction operations on the computer device 2800. Furthermore, the central processing unit 2822 may be configured to communicate with the storage medium 2830 and execute the series of instruction operations in the storage medium 2830 on the computer device 2800.

[0371] The computer device 2800 may also include one or more power supplies 2826, one or more wired or wireless network interfaces 2850, one or more input and output interfaces 2858, and / or one or more operating systems 2841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0372] In the embodiment of the present application, the central processing unit 2822 is used to execute the steps in the above-mentioned method embodiment. The specific implementation method of the central processing unit 2822 executing each of the above-mentioned steps is based on the same concept as the above-mentioned method embodiment in the present application, and the technical effects brought about are also the same as those in the above-mentioned embodiment of the present application. For specific details, please refer to the description of the method embodiment shown above in the present application, and will not be repeated here.

[0373] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0374] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course can also be implemented by means of dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, or a combination of a software product and a hardware product, and the computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., and includes a number of instructions for causing a computer device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0375] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0376] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a training device or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, computer, training device or data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A method for transferring lock resources, characterized in that: include: Obtain n actual runtime delays and n target latency requirements of n target threads, where one target thread corresponds to one actual runtime delay and one target latency requirement. The n target threads are threads currently competing for the same global mutex lock, and the n target threads run on at least two NUMA nodes, where n ≥ 2. Determining, according to the n actual runtime delays and the n target latency requirements, n out-of-order requirements of the n target threads, where one out-of-order requirement corresponds to one target thread, the out-of-order requirement being used to characterize the urgency with which the target thread needs to hold the global mutex lock; Based on the n out-of-order requirements, a degree of out-of-order for the global mutex lock is determined so that the global mutex lock is transferred based on the degree of out-of-order. The degree of out-of-order is used to represent a threshold value of the number of transfers each time the global mutex lock is held. Threads running on the same NUMA node are arranged adjacently on a lock transfer path.

2. The method according to claim 1, characterized in that Determining the disorder degree of the global mutex lock according to the n disorder requirements so that the global mutex lock is transferred based on the disorder degree includes: According to the disorder requirement of the target thread on the lock transfer path, the disorder degree of the global mutex lock is updated in real time during the transfer process of the global mutex lock, so that the global mutex lock is transferred based on the disorder degree updated in real time.

3. The method according to claim 2, characterized in that The method further comprises: In the case that the disorder degree is not updated for more than a preset period of time, the value of the disorder degree is increased according to a target preset gradient.

4. The method according to any one of claims 1 to 3, characterized in that The out-of-order requirements include: The upper limit of the number of transfers required by the target thread each time the global mutex is held.

5. The method according to any one of claims 1 to 4, characterized in that The first thread is one of the n target threads, the first thread includes m first code segments with delay requirements, m≥1, and obtaining the n actual running delays and n target delay requirements of the n target threads includes: Obtaining a first actual runtime delay and a first target latency requirement of a first code snippet currently being executed by a first thread; Each of the n target threads is used as the first thread, and the above steps are repeatedly performed until n first actual runtime delays and n first target latency requirements of the n first code snippets currently being run by each of the n target threads are obtained.

6. The method according to any one of claims 1 to 5, characterized in that Before obtaining the n actual running delays and n target delay requirements of the n target threads, the method further includes: The n target threads are determined from p threads, where the p threads are threads currently competing for the same global mutex, and p≥n.

7. The method according to claim 6, characterized in that Determining the n target threads from the p threads includes: The n target threads are determined based on p computing powers, where the p computing powers are the computing powers of the p cores running the p threads. One core runs one thread at the current moment. The n target computing powers are all greater than pn computing powers. The n target computing powers are the computing powers of the n target cores corresponding to the n target threads. The pn computing powers are the computing powers of the pn cores among the p cores excluding the n target cores.

8. The method according to claim 7, characterized in that The computing power of the p computing powers is reflected by the assigned p score values, and the computing power is positively correlated with the score value. The determining of the n target threads according to the p computing powers includes: Determining n target score values ​​from the p score values ​​that are greater than a score threshold; The n threads corresponding to the n target score values ​​are determined as the n target threads.

9. The method according to claim 8, characterized in that The method further comprises: When the contention level of the global mutex does not reach a preset condition, the score threshold is reduced according to a first preset gradient, where the preset condition is used to reflect whether the contention level of the global mutex is sufficient.

10. The method according to claim 8, characterized in that The method further comprises: When the contention level of the global mutex lock reaches a preset condition, the score threshold is increased according to a second preset gradient, where the preset condition is used to reflect whether the contention level of the global mutex lock is sufficient.

11. The method according to any one of claims 7 to 10, characterized in that The computing power is related to the core type of the core.

12. The method according to claim 11, characterized in that The p cores include at least two types of cores.

13. The method according to claim 12, characterized in that The core types include at least: Large, medium or small nucleus.

14. The method according to claim 6, characterized in that The p threads form a waiting queue, and determining the n target threads from the p threads includes: The n target threads are determined from the p threads based on a first-in-first-out (FIFO) principle.

15. A method for transferring lock resources, characterized in that: include: Obtain p actual runtime latencies and p target latency requirements for p threads, where one thread corresponds to one actual runtime latency and one target latency requirement. The p threads are currently competing for the same mutex. The p threads run on p cores, with one core currently running one thread. The p computing powers of the p cores have at least two different computing power values, where p ≥ 2. Determining, according to the p actual runtime delays and the p target delay requirements, an out-of-order waiting queue of the p threads waiting to compete for the mutex lock; Determine n target threads based on the p computing powers, where the n target computing powers are all greater than pn computing powers, the n target computing powers being the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers being the computing powers of the pn cores of the p cores excluding the n target cores, where p≥n; According to the out-of-order waiting queue, a contention queue in which the n target threads compete for the mutex lock is determined, so that the mutex lock is transferred based on the contention queue.

16. The method according to claim 15, characterized in that The computing power of the p computing powers is reflected by assigned p score values, and the computing power is positively correlated with the score value. Determining n target threads according to the p computing powers includes: Determining n target score values ​​from the p score values ​​that are greater than a score threshold; The n threads corresponding to the n target score values ​​are determined as the n target threads.

17. The method according to claim 16, characterized in that The method further comprises: When the contention level of the mutex does not reach a preset condition, the score threshold is reduced according to a first preset gradient, where the preset condition is used to reflect whether the contention level of the mutex is sufficient.

18. The method according to claim 16, characterized in that The method further comprises: When the contention level of the mutex lock reaches a preset condition, the score threshold is increased according to a second preset gradient, and the preset condition is used to reflect whether the contention level of the mutex lock is sufficient.

19. The method according to any one of claims 15 to 18, characterized in that The computing power is related to the core type of the core.

20. The method according to claim 19, characterized in that The p cores include at least two types of cores.

21. The method according to claim 20, characterized in that The core types include at least: Large, medium or small nucleus.

22. The method according to any one of claims 15 to 21, characterized in that The n target threads run on at least two NUMA nodes, the mutex includes a global mutex in a NUMA-aware lock, and after determining, based on the out-of-order wait queue, a competition queue for the n target threads to compete for the mutex, the method further includes: Determining, according to the n actual runtime delays and the n target latency requirements of the n target threads, n out-of-order requirements for each target thread, where each target thread corresponds to one out-of-order requirement, the out-of-order requirement being used to characterize the urgency with which the target thread needs to hold the global mutex lock; Based on the n out-of-order requirements, a degree of out-of-order for the global mutex lock is determined so that the global mutex lock is transferred based on the degree of out-of-order. The degree of out-of-order is used to represent a threshold value of the number of transfers each time the global mutex lock is held. Threads running on the same NUMA node are arranged adjacently on a lock transfer path.

23. The method according to claim 22, characterized in that Determining the disorder degree of the global mutex lock according to the n disorder requirements so that the global mutex lock is transferred based on the disorder degree includes: According to the disorder requirement of the target thread on the lock transfer path, the disorder degree of the global mutex lock is updated in real time during the transfer process of the global mutex lock, so that the global mutex lock is transferred based on the disorder degree updated in real time.

24. The method according to claim 23, wherein In the case that the disorder degree is not updated for more than a preset period of time, the value of the disorder degree is increased according to a target preset gradient.

25. The method according to any one of claims 22 to 24, characterized in that The out-of-order requirements include: The upper limit of the number of transfers required by the target thread each time the global mutex is held.

26. The method according to any one of claims 15 to 25, characterized in that The first thread is one of the p threads, the first thread includes m first code snippets with delay requirements, m≥1, and obtaining the p actual running delays and p target delay requirements of the p threads includes: Obtaining a first actual runtime delay and a first target latency requirement of a first code snippet currently being executed by a first thread; Each of the p threads is used as the first thread, and the above steps are repeatedly performed until p first actual runtime delays and p first target latency requirements of the p first code snippets currently being run by each of the p threads are obtained.

27. A device for transferring lock resources, characterized in that: Applied to a computer device, the computer device includes at least two NUMA nodes, and the apparatus includes: An acquisition module obtains n actual runtime delays and n target latency requirements of n target threads, where one target thread corresponds to one actual runtime delay and one target latency requirement. The n target threads are threads currently competing for the same global mutex lock and are running on at least two NUMA nodes, where n ≥ 2. A first determining module determines, based on the n actual runtime delays and the n target latency requirements, n out-of-order requirements of the n target threads, one out-of-order requirement corresponding to each target thread, the out-of-order requirement being used to characterize the urgency with which the target thread needs to hold the global mutex lock; The second determination module determines the disorder degree of the global mutex lock based on the n disorder requirements, so that the global mutex lock is transferred based on the disorder degree, and the disorder degree is used to represent the threshold of the number of transfers each time the global mutex lock is held. Threads running on the same NUMA node are arranged adjacent to each other on the lock transfer path.

28. The device according to claim 27, characterized in that The second determining module is specifically configured to: According to the disorder requirement of the target thread on the lock transfer path, the disorder degree of the global mutex lock is updated in real time during the transfer process of the global mutex lock, so that the global mutex lock is transferred based on the disorder degree updated in real time.

29. The device according to claim 28, characterized in that The second determining module is further configured to: In the case that the disorder degree is not updated for more than a preset period of time, the value of the disorder degree is increased according to a target preset gradient.

30. The device according to any one of claims 27 to 29, characterized in that The out-of-order requirements include: The upper limit of the number of transfers required by the target thread each time the global mutex is held.

31. The device according to any one of claims 27 to 30, characterized in that The first thread is one of the n target threads, and the first thread includes m first code segments with delay requirements, where m≥1. The acquisition module is specifically configured to: Obtaining a first actual runtime delay and a first target latency requirement of a first code snippet currently being executed by a first thread; Each of the n target threads is used as the first thread, and the above steps are repeatedly performed until n first actual runtime delays and n first target latency requirements of the n first code snippets currently being run by each of the n target threads are obtained.

32. The device according to any one of claims 27 to 31, characterized in that The acquisition module is further used to: Before obtaining n actual running delays and n target delay requirements of n target threads, the n target threads are determined from p threads, where the p threads are threads currently competing for the same global mutex, and p≥n.

33. The device according to claim 32, characterized in that The acquisition module is further configured to: The n target threads are determined based on p computing powers, where the p computing powers are the computing powers of the p cores running the p threads. One core runs one thread at the current moment. The n target computing powers are all greater than pn computing powers. The n target computing powers are the computing powers of the n target cores corresponding to the n target threads. The pn computing powers are the computing powers of the pn cores among the p cores excluding the n target cores.

34. The device according to claim 33, characterized in that The computing power of the p computing powers is reflected by the p assigned score values, and the computing power is positively correlated with the score value. The acquisition module is further configured to: Determining n target score values ​​from the p score values ​​that are greater than a score threshold; The n threads corresponding to the n target score values ​​are determined as the n target threads.

35. The device according to claim 34, characterized in that The device further comprises: an adjustment module; The adjustment module is configured to reduce the score threshold according to a first preset gradient when the contention level of the global mutex does not meet a preset condition, wherein the preset condition is used to reflect whether the contention level of the global mutex is sufficient.

36. The device according to claim 34, characterized in that The device further comprises: an adjustment module; The adjustment module is configured to increase the score threshold according to a second preset gradient when the contention level of the global mutex lock reaches a preset condition, wherein the preset condition is used to reflect whether the contention level of the global mutex lock is sufficient.

37. The device according to any one of claims 33 to 36, characterized in that The computing power is related to the core type of the core.

38. The device according to claim 37, characterized in that The p cores include at least two types of cores.

39. The device according to claim 38, characterized in that The core types include at least: Large, medium or small nucleus.

40. The device according to claim 32, wherein The p threads form a waiting queue, and the acquisition module is further configured to: The n target threads are determined from the p threads based on a first-in-first-out (FIFO) principle.

41. A device for transferring lock resources, characterized in that: Applied to a computer device, wherein the processor of the computer device includes at least p cores, where p ≥ 2, the apparatus comprises: An acquisition module is configured to obtain p actual runtime delays and p target latency requirements for p threads, where one thread corresponds to one actual runtime delay and one target latency requirement. The p threads are threads currently competing for the same mutex lock. The p threads run on p cores, with one core currently running one thread. The p computing powers of the p cores have at least two different computing power values, where p ≥ 2. A first determining module is configured to determine, based on the p actual runtime delays and the p target delay requirements, an out-of-order waiting queue of the p threads waiting to compete for the mutex lock; a second determining module, configured to determine n target threads based on the p computing powers, wherein the n target computing powers are all greater than pn computing powers, the n target computing powers being the computing powers of the n target cores corresponding to the n target threads, and the pn computing powers being the computing powers of the pn cores of the p cores excluding the n target cores, where p≥n; The third determining module is configured to determine, based on the out-of-order waiting queue, a contention queue in which the n target threads compete for the mutex lock, so that the mutex lock is transferred based on the contention queue.

42. The device according to claim 41, characterized in that The computing power of the p computing powers is reflected by the p assigned score values, and the computing power is positively correlated with the score value. The second determining module is specifically configured to: Determining n target score values ​​from the p score values ​​that are greater than a score threshold; The n threads corresponding to the n target score values ​​are determined as the n target threads.

43. The device according to claim 42, characterized in that The device further comprises: an adjustment module; The adjustment module is configured to reduce the score threshold according to a first preset gradient when the contention level of the mutex lock does not meet a preset condition, wherein the preset condition is used to reflect whether the contention level of the mutex lock is sufficient.

44. The device according to claim 42, characterized in that The device further comprises: an adjustment module; The adjustment module is configured to increase the score threshold according to a second preset gradient when the contention level of the mutex lock reaches a preset condition, wherein the preset condition is used to reflect whether the contention level of the mutex lock is sufficient.

45. The device according to any one of claims 41 to 44, characterized in that The computing power is related to the core type of the core.

46. ​​The device according to claim 45, characterized in that The p cores include at least two types of cores.

47. The device according to claim 46, characterized in that The core types include at least: Large, medium or small nucleus.

48. The device according to any one of claims 41 to 47, characterized in that The n target threads run on at least two NUMA nodes, the mutex lock includes a global mutex lock in a NUMA-aware lock, and the third determining module is further configured to: After determining, based on the out-of-order waiting queue, the contention queues of the n target threads competing for the mutex lock, determining, based on the n actual runtime delays and n target latency requirements of the n target threads, n out-of-order requirements of the n target threads, one out-of-order requirement corresponding to each target thread, the out-of-order requirement being used to represent the urgency with which the target threads need to hold the global mutex lock; Based on the n out-of-order requirements, a degree of out-of-order for the global mutex lock is determined so that the global mutex lock is transferred based on the degree of out-of-order. The degree of out-of-order is used to represent a threshold value of the number of transfers each time the global mutex lock is held. Threads running on the same NUMA node are arranged adjacently on a lock transfer path.

49. The device according to claim 48, characterized in that The third determining module is specifically configured to: According to the disorder requirement of the target thread on the lock transfer path, the disorder degree of the global mutex lock is updated in real time during the transfer process of the global mutex lock, so that the global mutex lock is transferred based on the disorder degree updated in real time.

50. The device according to claim 49, characterized in that The third determining module is further configured to: In the case that the disorder degree is not updated for more than a preset period of time, the value of the disorder degree is increased according to a target preset gradient.

51. The device according to any one of claims 48 to 50, characterized in that The out-of-order requirements include: The upper limit of the number of transfers required by the target thread each time the global mutex is held.

52. The device according to any one of claims 41 to 51, characterized in that The first thread is one of the p threads, and the first thread includes m first code segments with delay requirements, where m≥1. The acquisition module is specifically configured to: Obtaining a first actual runtime delay and a first target latency requirement of a first code snippet currently being executed by a first thread; Each of the p threads is used as the first thread, and the above steps are repeatedly performed until p first actual runtime delays and p first target latency requirements of the p first code snippets currently being run by each of the p threads are obtained.

53. A computer device, characterized in that The method comprises a memory and a processor, wherein the memory is used to store computer-readable instructions, and the processor is used to read the computer-readable instructions and implement the method according to any one of claims 1 to 26.

54. A computer storage medium, characterized in that Computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 26 is implemented.

55. A computer program product, characterized in that The computer program product includes computer-readable instructions, and when the computer-readable instructions are executed by a processor, the method according to any one of claims 1 to 26 is implemented.

Images