Weak memory sequence risk detection method and device, electronic equipment and storage medium

Abstract

The invention provides a weak memory sequence risk detection method and device, electronic equipment and a storage medium, and belongs to the technical field of computers. The method comprises the steps that event information of a plurality of data competition events is obtained based on operation information of threads synchronously operated at a plurality of detection positions, and the event information comprises instructions executed by at least two threads and function calling information of the instructions when data competition occurs; based on the function call information of each data competition event related instruction and the window size of the out-of-order execution window, a plurality of instruction pairs located in the same out-of-order execution window are obtained, and the out-of-order execution window is an instruction sequence for achieving out-of-order execution and dynamic scheduling of the instructions; each instruction pair comprises two instructions from the same data competition event; and when the memory barrier does not exist in the out-of-order execution window where any instruction pair is located, determining that the detection position corresponding to the instruction pair is the position with a weak memory order risk. The accuracy of the weak memory sequence risk detection result of the program is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and storage medium for detecting weak memory order risks. Background Art

[0002] In the computer field, Strong Memory Ordering (SMO) means that the processor is responsible for executing instructions in sequence. Weak Memory Ordering (WMO) means that the processor is not responsible for executing instructions in sequence. For programs developed in a strong memory order environment, when migrating from a strong memory order environment to a weak memory order environment, there may be a risk of incorrect execution of multiple threads running in parallel, resulting in logical errors in the functions to be implemented by the program, seriously affecting service reliability and stability. For this reason, when a program is migrated from a strong memory order environment to a weak memory order environment, it is necessary to perform weak memory order risk detection on the program.

[0003] Related technologies use static scanning to detect programs that need to migrate from a strong memory-ordering environment to a weak memory-ordering environment. Specifically, this method statically scans all global variables and atomic interfaces in the program's source code. The locations of all scanned global variables and atomic interfaces are provided to developers as locations with weak memory-ordering risks. Developers can then determine whether to insert memory barriers at each location.

[0004] Usually, the source code of a program contains a large number of global variables and atomic interfaces. The locations of some global variables and atomic interfaces do not have weak memory order risks. However, related technologies will scan all global variables and atomic interfaces as locations with weak memory order risks, and the detection results are not accurate enough. Summary of the Invention

[0005] The present invention provides a method, device, electronic device, and storage medium for detecting weak memory order risks, which can improve the accuracy of weak memory order detection results for a program when the program is migrated from a strong memory order environment to a weak memory order environment. The technical solution is as follows:

[0006] In a first aspect, a method for detecting a weak memory order risk is provided, the method comprising:

[0007] When a target program is running in a weak memory ordering environment, obtaining running information of each thread running synchronously at multiple detection locations, wherein the target program is a program developed in a strong memory ordering environment, and the detection locations are locations in the source code of the target program that may have a weak memory ordering risk;

[0008] Acquire, based on the running information of each thread running synchronously at the multiple detection locations, event information of multiple data race events, wherein the data race event refers to a memory access event to the same memory address by at least two threads running synchronously at the same detection location, and the event information includes instructions and function call information of the at least two threads when the data race occurs;

[0009] Based on function call information of instructions related to each data race event and the size of an out-of-order execution window, multiple instruction pairs located within the same out-of-order execution window are obtained. The out-of-order execution window is an instruction sequence that implements out-of-order execution and dynamic scheduling of instructions. Instructions within the same out-of-order execution window have a weak memory order risk, and each instruction pair includes two instructions resulting from the same data race event.

[0010] When there is no memory barrier in the out-of-order execution window where any instruction pair is located, it is determined that the detection position corresponding to the instruction pair is a position where there is a weak memory order risk.

[0011] In a second aspect, a device for detecting a weak memory order risk is provided, the device comprising:

[0012] a first acquisition module configured to acquire, when a target program is running in a weak memory ordering environment, execution information of each thread running synchronously at a plurality of detection locations, wherein the target program is a program developed in a strong memory ordering environment, and the detection locations are locations in the source code of the target program that may have a weak memory ordering risk;

[0013] a second acquisition module, configured to acquire event information of multiple data race events based on the running information of each thread running synchronously at the multiple detection locations, wherein the data race event refers to a memory access event to the same memory address by at least two threads running synchronously at the same detection location, and the event information includes instructions and function call information of the at least two threads when the data race occurs;

[0014] a third acquisition module, configured to acquire, based on function call information of instructions related to each data race event and a window size of the out-of-order execution window, multiple instruction pairs within the same out-of-order execution window, wherein the out-of-order execution window is an instruction sequence for implementing out-of-order execution and dynamic scheduling of instructions, the instructions within the same out-of-order execution window having a weak memory order risk, and each instruction pair including instructions originating from the same data race event;

[0015] The first determining module is configured to determine that a detection position corresponding to any instruction pair is a position having a weak memory order risk when no memory barrier exists in the out-of-order execution window where the instruction pair is located.

[0016] In a third aspect, an electronic device is provided, comprising a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the weak memory order risk detection method described in the first aspect.

[0017] In a fourth aspect, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and when the at least one computer program is executed by a processor, the weak memory order risk detection method as described in the first aspect can be implemented.

[0018] In a fifth aspect, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, it can implement the weak memory order risk detection method as described in the first aspect.

[0019] The beneficial effects of the technical solution provided by the embodiments of the present application are:

[0020] Usually, the problem of weak memory order is reflected in the process of program running. Before the target program is migrated to the weak memory order environment for running, this application inserts monitoring functions at multiple detection positions where there may be weak memory order risks in the target program, and then realizes dynamic monitoring of the target program based on the monitoring function at each detection position. Compared with the results obtained by the static scanning method, it is more reliable. During the operation of the target program, based on the running information of each thread running synchronously at each detection position, multiple data competition events are first screened out. Each data competition event reflects the relevant information of multiple synchronously running threads with data competition. Since multiple threads with data competition relationships do not necessarily have weak memory order problems, and there may be weak memory order problems between instructions in the same out-of-order execution window, in view of this, this application combines the function call information of the instructions related to each data competition event and the out-of-order execution window for further investigation. During the investigation, based on the function call information of the instructions related to each data race event, the two instructions in the data race event are obtained, and then it is determined whether these two instructions are in the same out-of-order execution window. If they are in the same out-of-order execution window and no memory barrier is added in the out-of-order execution window, the detection location corresponding to the data race event is determined to be the location where there is a weak memory order risk. Compared with the related technology that regards all detection locations as locations where there is a weak memory order risk, the detection result is more accurate. In general, for target programs developed in a strong memory environment, when performing weak memory order risk detection in a weak memory order environment, the accuracy of the detection results is improved through dynamic monitoring and combined investigation with the out-of-order execution window. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 Schematic diagram of an implementation environment involved in a weak memory order risk detection method provided in an embodiment of the present application;

[0023] Figure 2 This is a flow chart of a method for detecting weak memory order risk provided by an embodiment of the present application;

[0024] Figure 3 This is a flowchart of another weak memory order risk detection method provided by an embodiment of the present application;

[0025] Figure 4 1 is a schematic structural diagram of a device for detecting a weak memory order risk provided by an embodiment of the present application;

[0026] Figure 5 A structural block diagram of an electronic device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0027] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0028] It should be understood that the terms "each," "plurality," and "any" used in the embodiments of this application include two or more, "each" refers to each of the corresponding plurality, and "any" refers to any one of the corresponding plurality. For example, if a plurality of words includes 10 words, "each" refers to each of the 10 words, and "any" refers to any one of the 10 words.

[0029] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0030] Before executing the embodiments of the present application, the terms involved in the embodiments of the present application are first explained.

[0031] Both processes and threads are the basic units of program execution supported by the operating system. The operating system uses these basic units to implement concurrency for programs. A process is an independent unit used by the operating system for resource allocation and scheduling. A thread is an entity of a process and the basic unit of processor scheduling and dispatching. A thread essentially does not own system resources, possessing only a few resources essential for operation (such as the program counter, a set of registers, and a stack). However, a thread can share all resources owned by the process with other threads belonging to the same process. A thread can create and revoke another thread, and multiple threads in the same process can execute concurrently.

[0032] A data race occurs when multiple threads in a multithreaded program access and modify the same global variable or shared resource simultaneously without using synchronization mechanisms to protect the data. In this case, because the execution order of each thread is uncertain, unpredictable results may occur, leading to program errors or crashes.

[0033] Out-of-order execution technology allows the processor to execute instructions as quickly as possible, without having to follow the program code's order. Instead, it selects executable instructions according to reasonable rules, ensuring correct program execution results. In this execution method, the processor can increase program execution speed through parallelization and inference. The goal is to improve program execution throughput and single-instruction latency, thereby enhancing computer performance.

[0034] The Out-of-Order Execution Window (OOOEW) is a hardware component in the processor that enables out-of-order instruction execution and dynamic scheduling. Generally speaking, instructions within the OOOEW are executed out of order, while instructions outside the OOOEW are not.

[0035] A memory barrier, also known as a memory fence, is a type of synchronization barrier instruction. It acts as a synchronization point during random memory access by the processor or compiler, ensuring that all read and write operations prior to this point are completed before subsequent operations can begin. A memory barrier is a hardware or software mechanism that controls the order in which processors access memory when executing instructions, thereby ensuring the order of memory access across multiple processors and preventing data inconsistencies.

[0036] The function call hierarchy refers to the structure formed by the inter-function calls during program execution. Each function in a program has its own functionality and tasks. When the program needs to complete a specific task, it calls the corresponding function to perform the specific operation. During the function call process, each call first pauses the execution of the current function and switches to the called function. After the called function completes execution, execution returns to the original function. The structure of the function call hierarchy is similar to a stack. Each function call saves the current function's information on the stack, then executes the called function. After the called function completes execution, the saved information is popped off the stack and execution returns to the original function.

[0037] Happens-Before relationships are used to describe the relationships between multiple threads within a process, thereby determining whether data races exist between them. Happens-Before relationships specifically cover the following two cases: For two events Ei and Ej, if Ei and Ej belong to the same thread and Ei occurs before Ej, then i is determined to have occurred before j. If Ei is the sender of message G and Ej is the receiver of message G, then i is also determined to have occurred before j.

[0038] Dynamic instrumentation is a technology that dynamically inserts some special instructions or function calls into the program while the program is running. It is used to monitor the program's running process, thereby collecting program running information or modifying the program.

[0039] A state machine generally refers to a finite state machine, which is a mathematical computational model that represents a finite number of states and behaviors such as transitions and actions between these states.

[0040] An assertion error is an error in which a program calls the assert interface and produces an unexpected running result that is inconsistent with expectations, causing the program to exit abnormally.

[0041] A lock-free queue is a queue data structure that does not require locks to achieve concurrent access. It uses a special algorithm to avoid contention, thereby improving the efficiency of concurrent access. It typically uses atomic operations to ensure the correctness of concurrent access. Because lock-free queues avoid the use of locks, they can avoid the overhead and contention associated with locks, thereby improving system performance. Lock-free queues are widely used in highly concurrent environments, such as network servers and multi-threaded programming.

[0042] In the computer field, for programs developed in a strong memory order environment, if they run under a strong memory order architecture, the processor can ensure the sequential execution of the code in the program, and the actual execution order of the code is consistent with the writing order, and the memory access order will not be rearranged; if they run under a weak memory order architecture, the processor is not responsible for the sequential execution of the code in the program. In order to make the internal computing units as fully utilized as possible, the processor may change the execution order of the code in the program, resulting in the actual execution order of the code being inconsistent with the writing order, thereby causing weak memory order problems, which may cause logical errors in the functions to be implemented by the program, such as the occurrence of weak memory order assertion errors in lock-free queues. Such errors are usually sporadic and cannot be stably reproduced, seriously affecting service reliability and stability.

[0043] To mitigate weak memory ordering issues, many programs employ extremely strict ordering protection when migrating from a strong to a weak memory ordering environment, employing strong memory barriers. This approach significantly impairs program performance and reduces the concurrency of services. To mitigate this performance impact, improve concurrency, and ultimately optimize services, programs can be tested for memory ordering risks and then protected with memory barriers where such risks exist.

[0044] Related technologies can assist developers in detecting memory order risks by statically scanning all global variables and atomic interfaces in a program. However, since the source code of a program is usually complex, shared data is passed through multiple pointers, and the creation of multiple threads is also flexible and changeable, on the one hand, the static scanning method cannot completely and accurately identify which type of data is global shared data, resulting in a large area of ​​missed detection. On the other hand, the static scanning method will scan all global variables and atomic interfaces, some of which may not have weak memory order issues. The detection results of this detection method are not accurate enough. Furthermore, since the number of detected global variables and atomic interfaces is large, providing all detected global variables and atomic interfaces to developers for one-by-one inspection results in a low inspection efficiency.

[0045] In order to avoid over-protecting the program, improve the concurrent performance of the program, and improve the accuracy of the detection results and the detection efficiency of developers, an embodiment of the present application provides a weak memory order risk detection method. The method dynamically detects, stores and analyzes the shared memory access status when the program is running, locates all code locations in the program with data competition risks, and the detection results are relatively comprehensive, avoiding the problem of missed detection. Then, in the thread dimension, it analyzes whether the instructions with data competition risks are in the same out-of-order execution window. When the instructions with data competition risks are in the same out-of-order execution window, by detecting whether there is already a memory barrier in the out-of-order execution window, the code locations with weak memory order risks are further filtered out, and the detection results are more accurate. Then, in the dimension of the relationship between threads, it is determined whether there is also an out-of-order instruction window accessing the corresponding shared memory on other threads at the same time, thereby performing more fine-grained analysis and filtering, providing developers with a better memory barrier insertion method, further ensuring the accuracy of the detection results, and improving the detection efficiency.

[0046] Please refer to Figure 1 , which shows the implementation environment involved in the weak memory order risk detection method provided in the embodiment of the present application, and the implementation environment includes: an electronic device 101 and an electronic device 102, and the electronic device 101 and the electronic device 102 can be connected through a network, and the network can be a wired network or a wireless network, etc.

[0047] The electronic device 101 can provide a strong memory order environment for developers to develop programs, while the electronic device 102 can provide a weak memory order environment for running the programs developed by developers, thereby detecting code locations in the programs that have weak memory order risks.

[0048] The electronic devices 101 and 102 have strong computing capabilities and may be laptop computers, desktop computers, and the like.

[0049] The embodiment of the present application provides a method for detecting a weak memory order risk. Taking the electronic device 102 as an example, see Figure 2 , the method process provided in the embodiment of the present application includes:

[0050] 201. When a target program is running in a weak memory order environment, the running information of each thread running synchronously at multiple detection locations is obtained.

[0051] Among them, a strong memory order environment refers to an environment that can provide strong memory order protection, which mainly exists in systems with X86 architecture; a weak memory order environment refers to an environment that can provide weak memory order protection, which mainly exists in systems with ARM (Advanced RISC processors) architecture. During the program development phase, in order to better develop the functions of the program, it is usually developed in a strong memory order environment. For target programs developed in a strong memory order environment, when migrating them from a strong memory order environment to a weak memory order environment, there may be weak memory order problems because the processor is not responsible for the sequential execution in a weak memory order environment. For this reason, it is necessary to perform weak memory order risk detection on the target program.

[0052] In order to realize dynamic monitoring of the target program when the target program is running in a weak memory order environment, the embodiment of the present application will insert monitoring functions at multiple detection positions of the target program before running the target program in a weak memory order environment. Among them, the detection position is the position where the weak memory order risk may exist in the source code of the target program, including the position where operations on global variables and static variables (read / write) are performed, the position where function call operations are performed, the position where lock operations are performed, the position where thread creation and destruction operations are performed, etc. The monitoring function is used to monitor the running status of the source code at the insertion position of the target program, and the monitoring function can be a memory allocation function, etc. When inserting the monitoring function into the detection position of the target program, dynamic stub technology can be used to overload the monitoring function on the detection position of the program.

[0053] Thread execution information may include memory access operation types and accessed memory addresses, as well as thread attribute information, execution status, function call stack, and more. Memory access operation types include write and read operation types. Thread attribute information includes thread identifiers and the PID (Process Identifier) ​​of the process to which they belong. Operational statuses include newly created, running, blocked, waiting, timed-out waiting, and terminated. When a target program runs in a weak memory ordering environment, execution information for multiple threads running at multiple detection locations can be obtained based on the monitoring functions inserted at each detection location. Since each detection location may have multiple threads running, their execution times may vary. If the execution times of multiple threads overlap, they are considered synchronous threads. If the execution times of multiple threads do not overlap, they are not. Multiple threads with memory ordering risks are generally considered synchronous threads. Therefore, it is necessary to obtain synchronous threads from the threads running at each detection location. In order to obtain the synchronously running threads based on the execution time of the threads, the embodiment of the present application maintains a logical vector clock for each detection position, and then obtains the synchronously running threads at each detection position based on the execution time of each thread recorded by the logical vector clock.

[0054] Furthermore, in order to facilitate the management of the running information of multiple threads running synchronously at each detection position, the embodiment of the present application also treats the running information of each thread as an event and maintains a global event queue. When a new event is obtained when the target program is running, that is, the source code of the new thread execution program is detected, the new event is obtained, and the new event is added to the global event list.

[0055] Taking into account that different threads are not isolated but have certain relationships, for example, one thread can create or cancel another thread, in order to facilitate the management of the various threads involved in the operation of the target program, the embodiment of the present application will also construct a state machine based on the status information of each thread.

[0056] 202. Acquire event information of multiple data contention events based on running information of each thread running synchronously at multiple detection locations.

[0057] Among them, a data race event refers to a memory access event to the same memory address by at least two threads running synchronously at the same detection location. The event information includes the instructions and function call information of the at least two threads when the data race occurs, as well as the memory addresses of the memory space accessed by the at least two threads when the data race occurs, the context information of the at least two threads, etc. Taking any detection location as an example, for the running information of each thread running synchronously at the detection location, when obtaining the event information of the data race event at the detection location, the following method can be used:

[0058] 2021. When at least two threads access the same memory address, determine the relationship between the memory access operations of the at least two threads based on the memory access operation types and a preset relationship pattern of the at least two threads.

[0059] Based on the memory address of the memory space accessed by at least two threads, determine whether there are at least two threads accessing the same memory address. When there are at least two threads accessing the same memory address, obtain the memory access operation type of the at least two threads, and then determine the relationship between the memory access operations of the at least two threads based on the preset relationship pattern. The preset relationship pattern is used to indicate the relationship between different memory access operation types, which can be defined according to the Happens-Before relationship. The preset relationship pattern includes no competition relationship, read-write competition relationship, write-write competition relationship, etc. Specifically, if the memory access operation type of the two threads to the same memory address is a read operation, then the relationship between the memory access operations of the two threads is determined to be a no-competition relationship; if the memory access operation type of the two threads to the same memory address is a write operation, then the relationship between the memory access operations of the two threads is determined to be a write-write competition relationship; if the memory access operation types of the two threads to the same memory address are a read operation and a write operation respectively, then the relationship between the memory access operations of the two threads is determined to be a read-write competition relationship.

[0060] 2022. When the memory access operations of at least two threads are in a competitive relationship, the memory access operations of the at least two threads on the memory address are regarded as a data contention event.

[0061] When the relationship between the memory access operations of at least two threads is a read-write competition relationship, or a write-write competition relationship, it is determined that the relationship between the memory access operations of at least two threads is a competition relationship. When the relationship between the memory access operations of at least two threads is a competition relationship, the at least two threads in the competition relationship are treated as a data competition event. The threads involved in the data competition event are all or part of the multiple threads running synchronously at the detection position. If the memory access operations of the multiple threads running synchronously at the detection position all have a competition relationship, then the data competition event at the detection position includes all of the multiple threads running synchronously; if the memory access operations of some threads in the multiple threads running synchronously at the detection position have a competition relationship, then the data competition event at the detection position includes some of the multiple threads running synchronously.

[0062] Optionally, to facilitate acquisition of data race events at each detection location, embodiments of the present application further maintain a global state list. This global state list is used to store the state of the thread running at each detection location during the execution of the target program, including synchronization events observed at the current moment, the set of locks held by each currently running thread, the memory addresses accessed by each currently running thread in the memory space, etc. Based on the state of the thread running at each detection location in the global state list, data race events can be quickly detected.

[0063] 2023. Obtain instructions and function call information of at least two threads to obtain event information of a data race event.

[0064] For the at least two threads involved in the data contention event, in addition to obtaining the instructions and function call information of the at least two threads, the memory access read and write types of the at least two threads, the context information of the at least two threads, etc. will also be obtained, and the relevant information of the at least two threads obtained will be used as the event information of the data contention event.

[0065] 203. Based on the function call information of each data race event-related instruction and the window size of the out-of-order execution window, obtain multiple instruction pairs located in the same out-of-order execution window.

[0066] The out-of-order execution window is an instruction sequence that implements out-of-order execution and dynamic scheduling of instructions. Since instructions within the out-of-order execution window can be executed out of order, instructions within the same out-of-order execution window are subject to the risk of weak memory order. The window size of the out-of-order execution window is the number of instructions that the out-of-order execution window can carry, which is determined by the performance of the processor. Since the instructions within the same out-of-order execution window are the instructions fetched, decoded, and sequentially distributed by the processor to the target program, the execution time of these instructions is similar. Therefore, the window size of the out-of-order execution window not only restricts the instructions, but also actually reflects the similarity in the execution time of these instructions.

[0067] Specifically, based on the function call information of each data race event-related instruction and the window size of the out-of-order execution window, multiple instruction pairs located in the same out-of-order execution window are obtained, including the following steps:

[0068] 2031. Based on the function call information of each data contention event-related instruction, a data contention multi-tree model is constructed.

[0069] Based on the function call information of each data race event-related instruction, the following steps are included when constructing a data race multi-tree model:

[0070] 20311. Based on the function call information of each data contention event-related instruction, an initial data contention multi-branch tree model is constructed with the function call hierarchy relationship indicated by the function call information as the parent-child node relationship.

[0071] Each data contention event includes event information of at least two threads. The instructions in the thread where the data contention event occurs will call functions when executed. These functions form a function call hierarchy according to the calling relationship. For example, when instruction 1 is executed, it calls function 1, then calls function 2 in function 1, and then calls function 3 in function 2. This forms a hierarchy with function 1 as the parent node and function 2 as the child node, and another hierarchy with function 2 as the parent node and function 3 as the child node. This application is based on the function call information of the instructions related to each data contention event, and organizes the instructions related to each data contention event according to the function call hierarchy formed by the function call information of each instruction to form an initial data contention multi-tree model. The initial data contention multi-tree model includes multiple parent nodes and multiple leaf nodes under each parent node. Each parent node stores the event information of a data contention event. Each leaf node under the same parent node corresponds to an instruction in each thread running synchronously in the same data contention event. That is, multiple leaf nodes under the same parent node jointly represent a data contention event, and the leaf nodes under the same parent node have the same function call hierarchy relationship. Each leaf node stores the relevant information of a thread in the corresponding data contention event, including thread ID, memory access operation type, size of the accessed memory space, memory address, name of the called global variable or static variable, thread creation link information, function call information of the instruction in the thread when data contention occurs, etc.

[0072] For example, the relevant instructions of any data competition event include instruction 1, instruction 2 and instruction 3. When instruction 1 is executed, it calls the main function, then calls function A in the main function, and then calls function D in function A. When instruction 2 is executed, it calls the main function, then calls function A in the main function, and then calls function E in function A. When instruction 3 is executed, it calls the main function, then calls function A in the main function, and then calls function F in function A. Then, a tree structure can be formed with the main function as the parent node of function A, and function A as the parent node of function D, function E and function F. All relevant instructions of data competition events in the target program are organized according to this method, and finally an initial data competition multi-branch tree model can be obtained.

[0073] Although the above-mentioned initial data competition multi-branch tree model can characterize data competition events at multiple detection positions of the target program, the leaf nodes corresponding to the relevant instructions in each data competition event in the initial data competition multi-branch tree model are randomly arranged under the same parent node. When performing weak memory order detection based on these randomly arranged leaf nodes, it is necessary to detect whether the instructions corresponding to each leaf node and the instructions corresponding to other leaf nodes have weak memory order risks, and the detection efficiency is low. Considering that weak memory order risks mainly occur between two instructions with relatively close execution times, in order to improve detection efficiency, after constructing the initial data competition multi-branch tree model, the embodiment of the present application will also perform the following step 20312 to arrange multiple leaf nodes under the same parent node so that the execution times of the two adjacent instructions are relatively close. By arranging multiple leaf nodes under the same parent node, when performing weak memory order risk detection, there is no need to judge each leaf node separately from other leaf nodes. When it is judged based on two adjacent leaf nodes that a weak memory order risk exists at the detection position, it can be determined that a weak memory order risk exists at the detection position corresponding to the data competition event, which greatly improves detection efficiency.

[0074] 20312. Calculate the offset of the instruction corresponding to each leaf node relative to the function entry in the initial data competition multi-branch tree model.

[0075] The offset of an instruction relative to the function entry point refers to the number of bytes that the instruction is offset from the address of the function entry point that caused the data race. Typically, the address of a function entry point is fixed, and the offsets of multiple instructions relative to that function entry point can reflect the order in which the instructions call that function. The smaller the offset of an instruction relative to the function entry point, the earlier the instruction calls the function. Conversely, the larger the offset of an instruction relative to the function entry point, the later the instruction calls the function. The offset of each instruction relative to the function entry point can be directly read from the assembly instructions of the target program.

[0076] 20313. Sort multiple leaf nodes under the same parent node in the initial data competition multi-tree model according to the size of the offset to obtain the data competition multi-tree model.

[0077] In this application, multiple leaf nodes under the same parent node can be sorted in order of offset from small to large, or multiple leaf nodes under the same parent node can be sorted in order of offset from large to small. By sorting multiple leaf nodes under the same parent node, a data competition multi-branch tree model can be obtained.

[0078] 2032. Calculate the offset difference between two adjacent leaf nodes under the same parent node in the data competition multi-branch tree model.

[0079] 2033. When the difference between the offsets corresponding to any two adjacent leaf nodes is less than the window size, the instructions corresponding to the two leaf nodes are regarded as an instruction pair.

[0080] Generally speaking, the difference in offsets between two adjacent leaf nodes reflects the difference in execution time for the instructions corresponding to the two leaf nodes. Although instructions within the same out-of-order execution window can be executed out-of-order, the instructions within the same out-of-order execution window are the result of the processor fetching, decoding, and sequentially dispatching instructions to the target program. These instructions have similar execution times. Therefore, the difference in offsets between two adjacent leaf nodes can be used to determine whether the instructions corresponding to the two adjacent leaf nodes are within the same out-of-order execution window.

[0081] The embodiment of the present application calculates the difference in offsets corresponding to two adjacent leaf nodes under the same parent node, and then compares the difference with the window size of the out-of-order execution window. If the difference in offsets corresponding to any two adjacent leaf nodes is less than the window size, it can be determined that the two instructions corresponding to the two adjacent leaf nodes are within the same out-of-order execution window, and the instructions corresponding to the two leaf nodes are then regarded as an instruction pair. The detection position corresponding to the instruction pair may have a weak memory order problem, which needs to be further determined in step 204.

[0082] In another embodiment of the present application, when any data race event-related instructions are not within the same out-of-order execution window, it can be determined that there is no weak memory order risk at the detection location corresponding to the data race event.

[0083] 204. When there is no memory barrier in the out-of-order execution window where any instruction pair is located, determine that the detection position corresponding to the instruction pair is a position where there is a weak memory order risk.

[0084] Although the two instructions in each instruction pair may have a weak memory order risk within the same out-of-order execution window, if a memory barrier has been added to the out-of-order execution window where the instruction pair is located, they are protected by the memory barrier and the detection location corresponding to the instruction pair will not have a weak memory order problem. If a memory barrier is not added to the out-of-order execution window where the instruction pair is located, the detection location corresponding to the instruction pair will have a weak memory order risk. Based on the above content, it can be seen that whether a certain detection location has a weak memory order risk also depends on whether a memory barrier is added to the out-of-order execution window where the instruction pair corresponding to the detection location is located. Therefore, when multiple instruction pairs located in the same out-of-order execution window are obtained, the embodiment of the present application will also determine whether a memory barrier exists within the out-of-order execution window where each instruction pair is located. Taking any instruction pair as an example, when making a specific judgment, all instructions within the out-of-order execution window where the instruction pair is located can be obtained, and the source code of each instruction within the out-of-order execution window can be detected to determine whether the source code of the memory barrier is included. If the source code of each instruction within the out-of-order execution window does not include the source code of the memory barrier, it is determined that there is no memory barrier in the out-of-order execution window where the instruction pair is located.

[0085] Furthermore, when there is no memory barrier in the out-of-order execution window where any instruction pair is located, it can be determined that the detection location corresponding to the instruction pair is a location with a weak memory order risk. When there is a memory barrier in the out-of-order execution window where the instruction pair is located, it can be determined that there is no weak memory order risk in the detection location corresponding to the instruction pair.

[0086] The embodiment of the present application further investigates the detected data contention events based on the offset of the relevant instructions relative to the function entry and the out-of-order execution window in the data contention event, and screens out the detection locations with weak memory order risks. Compared with the related technology that uses all the locations of global variables and atomic interfaces as detection locations with weak memory order risks, the detection results are more accurate, fewer locations need to be detected by developers, and the detection efficiency of developers is improved.

[0087] To further improve the developer's detection efficiency, after using the above method to determine the detection locations with weak memory ordering risks, the embodiment of the present application will further screen these detection locations to select the target detection locations where memory barriers need to be added. Specifically, the following method can be used:

[0088] 2041. Acquire multiple target instruction intervals using the positions of the two instructions included in each target instruction pair within the corresponding out-of-order execution window as endpoints.

[0089] The target instruction pair is an instruction pair with a weak memory order risk, and the target instruction interval is an instruction interval within the out-of-order execution window with two instructions of the target instruction as endpoints.

[0090] 2042. Construct a hash table using the global variables or static variables called by the two instructions included in each target instruction pair as key values ​​and the corresponding target instruction interval as value values.

[0091] 2043. Based on the hash table, at least one target detection location that needs to add a memory barrier is screened out from the detection locations with weak memory risks.

[0092] Specifically, the value corresponding to each key value in the hash table is queried. When any key value corresponds to at least two value values, the detection position corresponding to the key value with the risk of weak memory order is determined as the target detection position. The target detection position is the detection position where it is recommended to add a memory barrier.

[0093] Furthermore, after screening out at least one target detection position that needs to add a memory barrier, the embodiment of the present application also sets the risk level of the detection position with a weak memory order risk to a first-level risk, and sets the risk level of the target detection position to a second-level risk, where the risk level of the second-level risk is higher than that of the first-level risk. Then, a first-level risk prompt is given to the detection position with a weak memory order risk, and a second-level risk prompt is given to at least one target detection position, wherein the intensity of the second-level risk prompt is higher than that of the first-level risk prompt. In this way, developers can prioritize the target detection positions with second-level risk prompts according to the risk levels from high to low, and then process the detection positions with first-level risk prompts based on the different levels of risk prompts. If the developer finds that a target detection position with a second-level risk prompt does need to add a memory barrier, the memory barrier can be added by modifying the source code at the target detection position. In this way, when the target detection position is executed, an internal screen barrier is added to the corresponding out-of-order execution window, and the weak memory order problem will not occur.

[0094] Optionally, to facilitate detection by developers, the detection positions corresponding to all first-level risk warnings and the target detection positions corresponding to second-level risk warnings, as well as the corresponding risk levels, and the function call relationships between nodes corresponding to the data competition feature multi-tree model can be organized into a list and provided to developers.

[0095] The method provided in the embodiment of the present application adopts dynamic instrumentation technology to observe data contention events and locate data contention. By constructing a data contention multi-tree model, the offset of the relevant instructions of each data contention event relative to the function entry is managed, thereby realizing the detection of potential weak memory order problems based on the out-of-order execution window, improving the accuracy of the detection results, and improving the detection efficiency of developers by providing risk warnings of different levels for the obtained detection results.

[0096] Compared with the static scanning method, the present application transfers the scanning from compile time to runtime, has higher scanning accuracy, provides more accurate problem output, and provides developers with location suggestions for adding multi-level memory barriers. At the same time, with the help of the constraints of the out-of-order execution window, the leaf nodes of the data competition multi-branch tree model are filtered, and the instruction positions and code positions with weak memory order problems are precisely located, which is better than the inefficient mode of leaving the scanning of the entire data to the developer's own judgment. In addition, in order to avoid weak memory order problems during the migration process, many programs adopt extremely strict order preservation methods, which greatly damages the concurrency performance of the program itself. The method of the embodiment of the present application fills the gap in the dynamic detection of memory order problems caused by the current program migration from a strong memory order environment to a weak memory order environment. Based on the above technology, memory barriers can be added only to the necessary parts of the migration process, thereby minimizing the damage to program performance, improving service concurrency performance, and achieving service optimization effects.

[0097] All of the above optional technical solutions can be combined in any way to form optional embodiments of the present application, and will not be described in detail here.

[0098] Figure 3 A flow chart of a method for detecting weak memory order risk provided by an embodiment of the present application is shown. The detection process includes:

[0099] The first step is to use dynamic instrumentation technology to insert a monitoring function at the detection location of the program. When the program is running, the running information of each thread running synchronously at each detection location is collected based on the inserted monitoring function. The running event of each thread is treated as an event, and a state machine is built based on the collected information.

[0100] The second step is to observe each new event and update the global state list based on the observed events.

[0101] The third step is to determine whether there is data contention between at least two threads based on the entire state list. If not, continue to observe. If so, build a data contention multi-tree model based on the relevant information of the data contention (i.e., the event information of the data contention event).

[0102] The fourth step is to perform a global search on the leaf nodes of the constructed data competition multi-branch tree model to determine whether the two data competition lines are in the same out-of-order execution window. If they are not in the same out-of-order execution window, no risk warning is required; if they are in the same out-of-order execution window, determine whether there is already a memory barrier in the out-of-order execution window. If so, no risk warning is required. If not, a first-level risk warning is issued.

[0103] The fifth step is to determine whether the global search is completed. If the search is completed, a hash table is constructed based on the risk instruction interval of the instruction pairs in the same out-of-order execution window, and then a search is performed to determine whether there are different intervals for the same group of variables. If so, a secondary risk warning is issued.

[0104] In the sixth step, the detection location groups corresponding to the first-level risk warnings and the second-level risk warnings are organized into a report and output to the developer.

[0105] In summary, the technical solution of this application has the following innovations compared to related technologies:

[0106] First, dynamic instrumentation technology is used to construct a state machine based on the current thread, call stack, memory address and other information collected at the instrumentation point when the program is running, and data competition events are observed based on the state machine. Data competition events are identified and detected when the state is updated, and the function call information and thread information corresponding to the data competition events are stored.

[0107] Second, based on the function call hierarchy derived from the function call information, the parent-child node relationships in the multitree are organized to form a data race multitree model. By fully scanning the leaf nodes of this data race multitree model and analyzing the offset difference between the corresponding instructions and the function entry point, global shared memory that does not require memory barrier protection can be filtered out, significantly focusing developers' attention when facing related issues.

[0108] Third, a hash table is used to store global variables or static variables corresponding to risky instructions, thereby performing secondary filtering on risky instructions to obtain the locations of instructions with higher risk levels.

[0109] Fourthly, with the help of the data competition multi-branch tree model, the instruction locations where memory barriers need to be added can be accurately located, and risk warnings of different levels can be provided, allowing developers to prioritize dealing with weak memory ordering issues with higher risk levels and then add memory barriers at relevant locations.

[0110] Please refer to Figure 4 , which shows a schematic diagram of the structure of a weak memory order risk detection device provided by an embodiment of the present application. The device can be implemented by software, hardware, or a combination of both, and becomes all or part of an electronic device. The device includes:

[0111] A first acquisition module 401 is configured to acquire, when a target program is running in a weak memory ordering environment, execution information of threads running synchronously at multiple detection locations, wherein the target program is a program developed in a strong memory ordering environment, and the detection locations are locations in the source code of the target program that may have a weak memory ordering risk;

[0112] A second acquisition module 402 is configured to acquire event information of multiple data race events based on the execution information of each thread running synchronously at multiple detection locations. The data race event refers to a memory access event to the same memory address by at least two threads running synchronously at the same detection location. The event information includes instructions and function call information of the at least two threads when the data race occurs.

[0113] A third acquisition module 403 is configured to acquire, based on function call information of instructions related to each data race event and the size of the out-of-order execution window, multiple instruction pairs within the same out-of-order execution window. The out-of-order execution window is an instruction sequence that implements out-of-order execution and dynamic scheduling of instructions. Instructions within the same out-of-order execution window have a weak memory order risk, and each instruction pair includes two instructions resulting from the same data race event.

[0114] The first determining module 404 is configured to determine that a detection location corresponding to any instruction pair is a location with a weak memory order risk when no memory barrier exists in the out-of-order execution window where any instruction pair is located.

[0115] In another embodiment of the present application, the device further comprises:

[0116] A monitoring module is used to insert monitoring functions at multiple detection locations of the target program, and the monitoring functions are used to monitor the running status of the source code at the insertion location of the target program;

[0117] The first acquisition module 401 is configured to acquire, when the target program is running in a weak memory order environment, running information of multiple threads running synchronously at multiple detection locations based on a monitoring function inserted at each detection location.

[0118] In another embodiment of the present application, the running information includes the memory access operation type and the accessed memory address. The second acquisition module 402 is used to determine the relationship between the memory access operations of at least two threads running synchronously at any detection position, when the memory addresses accessed by at least two threads are the same, based on the memory access operation types of at least two threads and a preset relationship pattern, the preset relationship pattern is used to indicate the relationship between different memory access operation types; when the relationship between the memory access operations of at least two threads is a competitive relationship, the memory access operations of at least two threads on the memory address are regarded as a data competition event; obtain the instructions of at least two threads and their function call information to obtain event information of the data competition event.

[0119] In another embodiment of the present application, the third acquisition module 403 is used to construct a data competition multi-tree model based on the function call information of the instructions related to each data competition event, where each leaf node under the same parent node in the data competition multi-tree model corresponds to an instruction in each thread running synchronously in the same data competition event, and the leaf nodes under the same parent node have the same function call hierarchy relationship, and the leaf nodes under the same parent node are sorted according to the offset size of the corresponding instructions; the difference in the offsets corresponding to two adjacent leaf nodes under the same parent node in the data competition multi-tree model is calculated; when the difference in the offsets corresponding to any two adjacent leaf nodes is less than the window size, the instructions corresponding to the two leaf nodes are regarded as an instruction pair.

[0120] In another embodiment of the present application, the third acquisition module 403 is used to construct an initial data competition multi-tree model based on the function call information of each data competition event-related instruction, with the function call hierarchy relationship indicated by the function call information as the parent-child node relationship; calculate the offset of the instruction corresponding to each leaf node in the initial data competition multi-tree model relative to the function entry; sort the multiple leaf nodes under the same parent node in the initial data competition multi-tree model according to the size of the offset to obtain the data competition multi-tree model.

[0121] In another embodiment of the present application, the device further comprises:

[0122] A fourth acquisition module, configured to acquire all instructions within the out-of-order execution window where the instruction pair is located;

[0123] A detection module, configured to detect whether the source code of each instruction in the out-of-order execution window includes source code of a memory barrier;

[0124] The second determining module is configured to determine that no memory barrier exists in the out-of-order execution window where the instruction pair is located when the source code of each instruction in the out-of-order execution window does not include the source code of the memory barrier.

[0125] In another embodiment of the present application, the device further comprises:

[0126] The third determination module is configured to determine that there is no weak memory order risk at the detection location corresponding to the data race event when none of the instructions related to the data race event are within the same out-of-order execution window; or

[0127] The fourth determination module is configured to determine that there is no weak memory order risk at a detection position corresponding to the instruction pair when a memory barrier exists in the out-of-order execution window where the instruction pair is located.

[0128] In another embodiment of the present application, the device further comprises:

[0129] a fifth acquisition module, configured to acquire a plurality of target instruction intervals using the positions of two instructions included in each target instruction pair within the corresponding out-of-order execution window as endpoints, wherein the target instruction pairs are instruction pairs with a weak memory order risk;

[0130] A construction module is used to construct a hash table using global variables or static variables called by two instructions included in each target instruction pair as key values ​​and corresponding target instruction intervals as values;

[0131] The screening module is used to screen out at least one target detection location that needs to add a memory barrier from the detection locations with weak memory risks based on the hash table.

[0132] In another embodiment of the present application, a screening module is used to query the value corresponding to each key value in the hash table; when any key value corresponds to at least two value values, the detection position corresponding to the key value that has a weak memory order risk is determined as the target detection position.

[0133] In another embodiment of the present application, the device further comprises:

[0134] The prompt module is used to provide a first-level risk prompt for a detection position with a weak memory order risk, and to provide a second-level risk prompt for at least one target detection position, wherein the risk level of the second-level risk is higher than the risk level of the first-level risk.

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

[0136] Figure 5 FIG2 shows a block diagram of an electronic device 500 according to an exemplary embodiment of the present application. Generally, the electronic device 500 includes a processor 501 and a memory 502 .

[0137] The processor 501 can be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 501 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state; the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 501 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 501 may also include an artificial intelligence processor, which is used to process computing operations related to machine learning.

[0138] The memory 502 may include one or more computer-readable storage media, which may be non-transitory computer-readable storage media, such as CD-ROMs (Compact Disc Read-Only Memory), ROMs, RAMs (Random Access Memory), magnetic tapes, floppy disks, and optical data storage devices. The computer-readable storage media may store at least one computer program, which, when executed, can implement the aforementioned weak memory order risk detection method.

[0139] Of course, the electronic device described above may also include other components, such as input / output interfaces and communication components. The input / output interface provides an interface between the processor and a peripheral interface module, which may be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and other devices.

[0140] Developers in this field can understand that Figure 5 The structure shown in the figure does not constitute a limitation on the electronic device 500, and the electronic device 500 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0141] An embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored. When the at least one computer program is executed by a processor, the above-mentioned weak memory order risk detection method can be implemented.

[0142] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it can implement the above-mentioned weak memory order risk detection method.

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

Claims

1. A method for detecting weak memory order risk, characterized in that: The method comprises: When a target program is running in a weak memory order environment, the running information of each thread running synchronously at multiple detection locations is obtained, the target program is a program developed in a strong memory order environment, and the detection location is a location in the source code of the target program where a weak memory order risk may exist; Based on the running information of each thread running synchronously at multiple detection positions, event information of multiple data competition events is obtained, wherein the data competition event refers to a memory access event of at least two threads running synchronously at the same detection position to the same memory address, and the event information includes instructions and function call information of at least two threads when data competition occurs; Based on the function call information of each data race event-related instruction and the window size of the out-of-order execution window, a plurality of instruction pairs located in the same out-of-order execution window are obtained, wherein the out-of-order execution window is an instruction sequence for implementing out-of-order execution and dynamic scheduling of instructions, and the instructions in the same out-of-order execution window have a weak memory order risk, and each instruction pair includes two instructions from the same data race event; When there is no memory barrier in the out-of-order execution window where any instruction pair is located, it is determined that the detection position corresponding to the instruction pair is a position where there is a risk of weak memory order.

2. The method according to claim 1, characterized in that When the target program is running in a weak memory order environment, before obtaining the running information of each thread running synchronously at multiple detection locations, the method further includes: Inserting monitoring functions at multiple detection positions of the target program, wherein the monitoring functions are used to monitor the running conditions of the source code at the insertion position of the target program; When the target program is running in a weak memory order environment, the operation information of each thread running synchronously at multiple detection locations is obtained, including: When the target program is running in a weak memory order environment, based on the monitoring function inserted at each detection position, the running information of multiple threads running synchronously at multiple detection positions is obtained.

3. The method according to claim 1, characterized in that The operation information includes a memory access operation type and an accessed memory address, and the operation information of each thread synchronously running based on multiple detection locations is used to obtain event information of multiple data competition events, including: For at least two threads running synchronously at any detection position, when the memory addresses accessed by the at least two threads are the same, determining the relationship between the memory access operations of the at least two threads based on the memory access operation types of the at least two threads and a preset relationship mode, wherein the preset relationship mode is used to indicate the relationship between different memory access operation types; When the memory access operations of the at least two threads are in a competitive relationship, treating the memory access operations of the at least two threads on the memory address as a data competition event; Instructions of the at least two threads and function call information thereof are acquired to obtain event information of the data competition event.

4. The method according to claim 1, characterized in that: The method of acquiring multiple instruction pairs located in the same out-of-order execution window based on the function call information of each data competition event related instruction and the window size of the out-of-order execution window includes: Based on the function call information of the instructions related to each data competition event, a data competition multi-branch tree model is constructed, in which each leaf node under the same parent node corresponds to an instruction in each thread running synchronously in the same data competition event, the leaf nodes under the same parent node have the same function call hierarchy relationship, and the leaf nodes under the same parent node are sorted according to the offset size of the corresponding instruction; Calculate the difference in offsets corresponding to two adjacent leaf nodes under the same parent node in the data competition multi-branch tree model; When the difference in offsets corresponding to any two adjacent leaf nodes is smaller than the window size, the instructions corresponding to the two leaf nodes are regarded as an instruction pair.

5. The method according to claim 4, characterized in that The method of constructing a data competition multi-branch tree model based on function call information of each data competition event-related instruction includes: Based on the function call information of each data competition event-related instruction, the function call hierarchy relationship indicated by the function call information is used as the parent-child node relationship to construct an initial data competition multi-branch tree model; Calculate the offset of the instruction corresponding to each leaf node in the initial data competition multi-branch tree model relative to the function entry; According to the size of the offset, multiple leaf nodes under the same parent node in the initial data competition multi-branch tree model are sorted to obtain the data competition multi-branch tree model.

6. The method according to claim 1, characterized in that When there is no memory barrier in the out-of-order execution window where any instruction pair is located, before determining that the detection position corresponding to the instruction pair is a position where there is a risk of weak memory order, the method further includes: Obtain all instructions in the out-of-order execution window where the instruction pair is located; Detecting whether the source code of each instruction in the out-of-order execution window includes source code of a memory barrier; When the source code of each instruction in the out-of-order execution window does not include the source code of the memory barrier, it is determined that there is no memory barrier in the out-of-order execution window where the instruction pair is located.

7. The method according to claim 1, characterized in that The method further comprises: When any data race event-related instructions are not in the same out-of-order execution window, it is determined that there is no weak memory order risk at the detection location corresponding to the data race event; or When a memory barrier exists in the out-of-order execution window where the instruction pair is located, it is determined that a detection position corresponding to the instruction pair does not have a weak memory order risk.

8. The method according to any one of claims 1 to 7, characterized in that When there is no memory barrier in the out-of-order execution window where any instruction pair is located, after determining that the detection position corresponding to the instruction pair is a position where there is a risk of weak memory order, the method further includes: Taking the positions of two instructions included in each target instruction pair in the corresponding out-of-order execution window as endpoints, a plurality of target instruction intervals are acquired, wherein the target instruction pair is an instruction pair having a weak memory order risk; A hash table is constructed using the global variables or static variables called by the two instructions included in each target instruction pair as key values ​​and the corresponding target instruction interval as value values; Based on the hash table, at least one target detection position to which a memory barrier needs to be added is screened out from detection positions with weak memory risks.

9. The method according to claim 8, characterized in that The step of screening out at least one target detection position to which a memory barrier needs to be added from detection positions with weak memory risks based on the hash table includes: Query the value corresponding to each key value in the hash table; When any key value corresponds to at least two value values, the detection position corresponding to the key value and having a weak memory order risk is determined as the target detection position.

10. The method according to claim 8, characterized in that After screening out at least one target detection position where a memory barrier needs to be added, the method further includes: A first-level risk warning is given to the detection position with a weak memory order risk, and a second-level risk warning is given to the at least one target detection position, wherein the risk level of the second-level risk is higher than that of the first-level risk.

11. A weak memory order risk detection device, characterized in that: The device comprises: A first acquisition module is used to acquire the running information of each thread running synchronously at multiple detection locations when the target program is running in a weak memory order environment, the target program is a program developed in a strong memory order environment, and the detection location is a location in the source code of the target program where a weak memory order risk may exist; A second acquisition module is used to acquire event information of multiple data competition events based on the running information of each thread running synchronously at multiple detection positions, wherein the data competition event refers to a memory access event of at least two threads running synchronously at the same detection position to the same memory address, and the event information includes instructions and function call information of at least two threads when data competition occurs; A third acquisition module is used to acquire multiple instruction pairs located in the same out-of-order execution window based on function call information of instructions related to each data competition event and the window size of the out-of-order execution window, wherein the out-of-order execution window is an instruction sequence for implementing out-of-order execution and dynamic scheduling of instructions, and the instructions in the same out-of-order execution window have a weak memory order risk, and each instruction pair includes instructions from the same data competition event; The first determination module is used to determine that a detection position corresponding to any instruction pair is a position with a weak memory order risk when there is no memory barrier in the out-of-order execution window where the instruction pair is located.

12. An electronic device, characterized in that: It comprises a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the weak memory order risk detection method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by a processor, the method for detecting weak memory order risks according to any one of claims 1 to 10 can be implemented.

14. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method for detecting weak memory order risk according to any one of claims 1 to 10 can be implemented.

Images