Thread synchronization exception handling method, device and equipment

Abstract

The invention provides an exception handling method, device and equipment for thread synchronization, and the method comprises the steps: obtaining the execution states of at least two synchronization threads through the utilization of pile codes inserted at a preset synchronization point and a return statement in advance in the process of executing a target program, and carrying out the exception handling of the at least two synchronization threads according to the execution states of the at least two synchronization threads, whether the at least two synchronous threads have the deadlock risk in the process of executing the target program or not is detected, the potential deadlock risk can be identified, the false report and / or missing report risk of the deadlock risk can be reduced, and therefore the detection accuracy of the deadlock risk can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of thread synchronization, and particularly relates to a thread synchronization exception processing method, device and equipment. BACKGROUND

[0002] A graphics processing unit (GPU) is a processor specially designed for parallel computing, widely used in high-performance computing, artificial intelligence, graphics rendering and scientific computing, etc. Its core feature is to support large-scale multi-thread parallel execution, and can handle thousands to hundreds of thousands of computing tasks at the same time.

[0003] In a GPU, threads execute different tasks in parallel, but some computing stages require threads to coordinate at certain points to ensure data consistency or task correctness. This coordination is achieved through synchronization instructions, that is, setting synchronization points (also known as barriers) in program execution, requiring related threads to reach the synchronization point and wait until all specified threads reach the synchronization point before continuing execution. However, in a multi-thread synchronization scenario, various abnormal problems may occur, which are often difficult to debug and can cause program performance degradation or even crashes. SUMMARY

[0004] Therefore, the embodiments of the present application aim to provide a thread synchronization exception processing method, device and equipment, which can improve the reliability of program execution.

[0005] In a first aspect, the present application provides a thread synchronization exception processing method, comprising: obtaining execution states of at least two synchronization threads by using a stake code inserted in advance at a preset synchronization point and a return statement during execution of a target program; and detecting whether there is a deadlock risk of the at least two synchronization threads during execution of the target program according to the execution states of the at least two synchronization threads.

[0006] In one embodiment, the execution states of the at least two synchronization threads are obtained by using the stake code inserted in advance at the preset synchronization point and the return statement, comprising: writing the execution states of the synchronization threads in an array form into a global memory of a graphics processing unit by using the stake code inserted in advance at the preset synchronization point and the return statement; and detecting whether there is a deadlock risk of the at least two synchronization threads during execution of the target program according to the execution states of the at least two synchronization threads, comprising: reading the execution states of the at least two synchronization threads from the global memory of the graphics processing unit to detect whether there is a deadlock risk of the at least two synchronization threads during execution of the target program.

[0007] In one embodiment, the execution status of each synchronization thread is written into the global memory of the graphics processing unit in the form of an array, including: writing the execution status of the synchronization thread into the global memory of the graphics processing unit in the form of a single-flag array, each element in the single-flag array indicating that the synchronization thread is executing, waiting at a synchronization point, or has returned; and the index in the single-flag array identifying the synchronization thread.

[0008] In one embodiment, the execution status of each synchronization thread is written into the global memory of the graphics processing unit in the form of an array, including: writing the execution status of the synchronization thread into the global memory of the graphics processing unit in the form of a double-flag array, each element in the double-flag array indicating that the synchronization thread is executing, waiting at a synchronization point, or has returned; the double-flag array including a first index and a second index pointing to the same element, the first index being used to switch two state flags to identify the currently used state array, and the second index being used to identify the synchronization thread, wherein the currently used state flag is switched through the first index after the synchronization thread passes through the synchronization point; and obtaining the execution status of at least two synchronization threads, including: obtaining the elements pointed to by the at least two synchronization threads when the first index is the same.

[0009] In one embodiment, according to the execution status of at least two synchronization threads, it is detected whether there is a risk of deadlock in the execution of the target program by the at least two synchronization threads, including: according to the execution status of the at least two synchronization threads, it is detected whether the execution status of the at least two synchronization threads at the same synchronization point meets a preset consistency requirement; and if the execution status of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement, it is determined that there is a risk of deadlock in the execution of the target program by the at least two synchronization threads.

[0010] In one embodiment, the at least two synchronization threads are synchronization threads within a thread block; and the detection of whether the execution status of the at least two synchronization threads at the same synchronization point meets a preset consistency requirement, including: if it is detected that the execution status of the at least two synchronization threads is all waiting at the same synchronization point, it is determined that the execution status of the at least two synchronization threads at the same synchronization point meets the preset consistency requirement; if it is detected that the execution status of the at least two synchronization threads is waiting at different synchronization points, it is determined that the execution status of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement; and if it is detected that the execution status of part of the at least two synchronization threads is waiting at a synchronization point, and the execution status of part of the at least two synchronization threads is returned, it is determined that the execution status of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement.

[0011] In an embodiment, the at least two synchronization threads are synchronization threads within the grid; and the detecting whether the execution states of the at least two synchronization threads at the same synchronization point satisfy the preset consistency requirement comprises: if it is detected that the execution states of the at least two synchronization threads are all waiting at the same synchronization point, it is determined that the execution states of the at least two synchronization threads at the same synchronization point satisfy the preset consistency requirement; and if it is detected that the execution states of part of the at least two synchronization threads are waiting at the synchronization point and the execution states of part of the at least two synchronization threads have returned, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not satisfy the preset consistency requirement.

[0012] In an embodiment, the exception handling method further comprises: if it is detected that there is a deadlock risk in the execution of the target program by the at least two synchronization threads, outputting error information and terminating the at least two synchronization threads.

[0013] In an embodiment, before the execution of the target program, the exception handling method further comprises: compiling source code of the target program into an intermediate representation, inserting a stake code at a preset synchronization point and a return statement based on the intermediate representation; and converting the intermediate representation into machine code to execute the target program.

[0014] In a second aspect, the present application provides an exception handling apparatus for thread synchronization, comprising: an acquisition module configured to acquire execution states of at least two synchronization threads by using a stake code inserted in advance at a preset synchronization point and a return statement during execution of a target program; and a detection module configured to detect whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads according to the execution states of the at least two synchronization threads.

[0015] In a third aspect, the present application provides an electronic device, comprising: one or more processors; and a memory associated with the one or more processors, the memory being configured to store program instructions, the program instructions being configured to perform the exception handling method for thread synchronization of the first aspect when read and executed by the one or more processors.

[0016] In a fourth aspect, the present application provides a computer-readable storage medium, the computer-readable storage medium storing a computer program, the computer program being configured to implement the exception handling method for thread synchronization of the first aspect when executed.

[0017] In a fifth aspect, the present application provides a computer program product, the computer program product comprising a computer program, the computer program being configured to implement the exception handling method for thread synchronization of the first aspect when executed.

[0018] The thread synchronization exception processing method, device and equipment provided by the embodiments of the present application can detect whether potential deadlock risks caused by synchronization instructions occur in the execution of the target program by each synchronization thread according to the execution state of each synchronization thread, and improve the reliability of program execution. In addition, compared with the static detection method, the deadlock risk detection mechanism provided in the program execution process has higher detection accuracy. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Figure 1 A schematic flowchart of a thread synchronization exception processing method provided by the embodiments of the present application.

[0021] Figure 2 A schematic flowchart of thread block synchronization detection provided by the embodiments of the present application.

[0022] Figure 3 A schematic flowchart of grid synchronization detection provided by the embodiments of the present application.

[0023] Figure 4 A thread synchronization timing diagram provided by the embodiments of the present application.

[0024] Figure 5 Another thread synchronization timing diagram provided by the embodiments of the present application.

[0025] Figure 6 A schematic block diagram of a thread synchronization exception processing device provided by the embodiments of the present application.

[0026] Figure 7 A schematic block diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0027] The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0028] The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in the embodiments of the present application and the accompanying claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0029] It should be understood that the term "and / or" used herein only means an association relationship of the associated objects, and means that there can be three relationships, for example, A and / or B, which can represent the three cases of A existing alone, A and B existing together, and B existing alone. In addition, the character " / " in this paper generally represents that the front and rear associated objects are in an "or" relationship.

[0030] Depending on the context, the word "if" as used herein can be interpreted to mean "when" or "while" or "in response to determining" or "in response to detecting." Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" can be interpreted to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]."

[0031] First, the terms involved in the present application are explained below.

[0032] Thread: The smallest execution unit of a GPU, each thread has independent registers and program counters, and executes the same kernel function but processes different data.

[0033] Thread block: A collection of threads, usually containing tens to hundreds of threads. Threads within a block can efficiently exchange data through the shared memory of the thread block.

[0034] Grid: A collection of multiple thread blocks. A grid corresponds to a kernel launch, and is responsible for processing larger-scale data as a whole.

[0035] Intra-thread block synchronization: In the same thread block, all threads are synchronized at a certain synchronization point and wait until all threads reach it before continuing execution. All threads must execute to this synchronization point, otherwise the program may appear deadlock or behavior undefined. For example, the synchronization instruction can be__syncthreads() in Compute Unified Device Architecture (CUDA).

[0036] Intra-grid synchronization: Coordination between multiple thread blocks within a grid, causing all threads in a grid to wait at a synchronization point. All threads must execute to this point, otherwise the program may deadlock or behave undefined. For example, the synchronization instruction can be __syncblocks() in some architectures.

[0037] Custom synchronization points: A more flexible synchronization mechanism that allows developers to define arbitrary thread groups to synchronize, not limited to thread blocks or warps.

[0038] Synchronization points: Also known as barriers, are positions where multiple threads agree to wait for each other, ensuring a specific execution order before proceeding. The core role is to coordinate the execution pace of threads, ensuring that threads synchronize at critical nodes before executing subsequent operations.

[0039] Synchronization deadlock: In a multi-threaded program, some threads wait at a synchronization point, while other threads fail to reach the same synchronization point, causing some threads to wait indefinitely, and the program to hang indefinitely.

[0040] In the research, the inventor found that in GPU, threads execute different tasks in parallel, but some computing stages require threads to coordinate at specific points to ensure data consistency or task correctness. This coordination is achieved through synchronization instructions, which define synchronization points in program execution, requiring related threads to reach the synchronization point and wait until all specified threads reach the synchronization point before continuing execution. However, the complexity of synchronization instructions, especially their use in branch divergent code, poses a potential risk of synchronization deadlock. For example, the following two synchronization deadlock scenarios: (1) Branch partial synchronization: In branch divergent code, some threads may execute synchronization instructions, while other threads skip synchronization or exit early. In this scenario, for example, if-else statements, the first half of the threads within the same thread block wait at __syncthreads() for all threads within the thread block to reach, but the second half of the threads directly return, causing the waiting threads to be unable to continue execution, and the program to hang. This problem is particularly common in GPU architectures that strictly require all threads to participate in synchronization.

[0041] (2) Synchronization instruction mismatch: When different types of synchronization instructions are used in branches, threads may wait at different synchronization points, forming a deadlock of mutual waiting. In this scenario, for example, the first half of the threads within the same thread block wait at the thread block synchronization point, while the second half of the threads wait at the grid synchronization point. Due to the different ranges and semantics of the two synchronization points, threads cannot uniformly reach the same synchronization point, resulting in a deadlock.

[0042] To address the synchronization deadlock problem, the related art mainly uses a static checking method, such as relying on a static analysis tool (for example, a compiler-based static checker) to detect potential synchronization deadlocks during code compilation. However, this method has the following problems: (1) Difficulty in modeling dynamic behavior of branch divergence: Branch divergence (for example, if-else) in GPU programs usually depends on program runtime conditions (for example, thread ID, input data). Static checking methods cannot accurately predict all possible execution paths at compile time, so this method may miss some deadlock scenarios, resulting in unidentifiable deadlock risks.

[0043] (2) Complexity of cross-synchronization point dependency: Deadlocks may involve the interaction of multiple synchronization points (for example, __syncthreads() and __syncblocks()). Static checking methods need to construct a complete control flow graph (CFG), but the parallelism and large number of threads of GPU programs make the CFG analysis extremely complex, so this method may not be able to accurately track the waiting state of threads at different synchronization points, especially when the synchronization point type is dynamically selected in branches.

[0044] (3) Platform differences in hardware semantics: Different GPU architectures have different implementations and tolerances for synchronization instructions. For example, some architectures allow some threads to skip __syncthreads(), while other architectures require all threads to participate. Static checking methods are usually based on the semantics of a specific platform, and are difficult to adapt to all architectures, so this method lacks cross-platform universality and cannot handle the diversity of hardware constraints.

[0045] (4) Conservativeness of static checking: To avoid false negatives, static checking methods usually make conservative assumptions that any potential synchronization inconsistency may be an error. However, this conservatism can lead to false positives for legal code, resulting in high false positive rates and increased developer debugging burden.

[0046] (5) Lack of program runtime context: Static checking methods cannot access program runtime information (such as thread state, synchronization point arrival conditions), making it difficult to simulate the actual execution order and state of threads. Therefore, this method cannot detect deadlocks that only occur at runtime, and cannot capture deadlock scenarios caused by dynamic behavior at runtime.

[0047] In summary, the static checking method used in the related art has the following limitations: (1) False positives and false negatives coexist: legal synchronization patterns may be falsely reported as errors, or deadlocks in dynamic branches may be missed.

[0048] (2) High computational overhead: Analyzing the control flow and data flow of large-scale GPU programs requires a large amount of computational resources, affecting the efficiency of compilation.

[0049] (3) Limited error diagnosis: Usually only provides the code location of potential errors, lacks detailed program runtime context, and is difficult to help developers quickly locate problems.

[0050] (4) Platform dependency: Usually optimized for a specific programming model (e.g. CUDA), difficult to adapt to other GPU architectures or emerging parallel frameworks.

[0051] To solve the above problems, the present application provides a thread synchronization exception handling method. Figure 1 A schematic flowchart of a thread synchronization exception handling method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the thread synchronization exception handling method can include the following steps: Figure 1 Step 101: During the execution of the target program, the execution states of at least two synchronization threads are obtained by using the inserted stub code at the preset synchronization points and return statements.

[0052] Step 102: According to the execution states of the at least two synchronization threads, it is detected whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads.

[0053] Wherein, the execution state can include: running, returned, waiting at a certain synchronization point. Optionally, the execution state can be stored in integer form, for example, 0 represents that the synchronization thread is running, -1 represents that the synchronization thread has returned, 1 represents that the synchronization thread is waiting at the synchronization point with ID 1, 2 represents that the synchronization thread is waiting at the synchronization point with ID 2, and so on.

[0054] As can be seen from the above flow, by inserting the stub code at the preset synchronization points and return statements in advance, the execution states of the synchronization threads are monitored in real time during the execution of the target program by using the stub code, so that according to the execution states of the synchronization threads, it can be detected whether there is a potential deadlock risk caused by synchronization instructions in the execution of the target program by the synchronization threads, and the reliability of program execution is improved. In addition, compared with the static detection method, the deadlock risk detection mechanism provided during the program execution has higher detection accuracy.

[0055] The steps in the above flow and the effects that can be further produced will be described in detail below with respect to embodiments.

[0056] In the embodiments of the present application, the synchronization thread refers to the thread that needs to be coordinated for synchronization.

[0057] ​In an embodiment, before executing the target program, the thread-synchronized exception handling method further comprises: compiling source code of the target program into an intermediate representation, inserting a stub code at a preset synchronization point and a return statement based on the intermediate representation; and converting the intermediate representation into machine code to execute the target program.

[0058] The intermediate representation is an intermediate code form between source code and machine code, and is suitable for program analysis and optimization. The stub code is inserted into the original program to insert auxiliary detection logic, and the program running information or the program behavior can be collected through the inserted stub code. Thus, the source code of the target program can be compiled into an intermediate representation in the compiling stage, and a stub code can be inserted at a preset synchronization point and a return statement based on the intermediate representation, and then the intermediate representation is converted into machine code to execute the target program. In the execution process of the target program, the original code is replaced by the inserted stub code, so that the execution state of each synchronization thread can be monitored in real time by using the stub code, and the potential deadlock risk can be detected.

[0059] In the embodiment of the present application, although the deadlock detection in the execution process of the target program may introduce a small performance overhead, by inserting the stub code in the intermediate representation, the performance overhead can be further reduced, and the detection accuracy and the code debugging efficiency can be improved.

[0060] In the embodiment of the present application, the stub code can distinguish different synchronization points by identifying the ID of the synchronization point.

[0061] The following takes the thread block synchronization, the grid synchronization and the return statement as an example to introduce the deadlock detection mechanism of the present application.

[0062] The present application obtains the execution state of at least two synchronization threads by using the stub code inserted at the preset synchronization point (including the thread block synchronization point and the grid synchronization point) and the return statement in the execution process of the target program, and judges whether the execution state of each synchronization thread reaches an agreement at the same synchronization point by comparing the execution state of each synchronization thread, so as to identify the potential deadlock risk. That is, according to the execution state of at least two synchronization threads, whether at least two synchronization threads exist a deadlock risk in the execution process of the target program is detected, including: according to the execution state of at least two synchronization threads, whether the execution state of at least two synchronization threads at the same synchronization point meets a preset consistency requirement is detected; if the execution state of at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement, it is determined that at least two synchronization threads exist a deadlock risk in the execution process of the target program.

[0063] In the present application, the underlying synchronization mechanism requirement of the deadlock detection mechanism is implemented based on synchronization points. The synchronization function can be referred to as a synchronization barrier function. For example, __syncthreads(), __syncblocks(), and the like.

[0064] In an embodiment, taking a synchronization point within a thread block (for example, __syncthreads()) as an example, if at least two synchronization threads are synchronization threads within a thread block, the execution state of the at least two synchronization threads at the same synchronization point is detected to determine whether it meets a preset consistency requirement, including: if it is detected that the execution state of the at least two synchronization threads is waiting at the same synchronization point, it is determined that the execution state of the at least two synchronization threads at the same synchronization point meets the preset consistency requirement; if it is detected that the execution state of the at least two synchronization threads is waiting at different synchronization points, it is determined that the execution state of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement; if it is detected that, among the at least two synchronization threads, the execution state of part of the synchronization threads is waiting at the synchronization point, and the execution state of part of the synchronization threads is returned, it is determined that the execution state of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement.

[0065] If the execution state of the at least two synchronization threads at the same synchronization point meets the preset consistency requirement, it can be determined that the at least two synchronization threads do not have a deadlock risk during the execution of the target program, and the at least two synchronization threads can continue to execute. If the execution state of the at least two synchronization threads at the same synchronization point does not meet the preset consistency requirement, it can be determined that the at least two synchronization threads have a deadlock risk during the execution of the target program, and an exception handling can be performed, for example, outputting an error message and terminating the at least two synchronization threads.

[0066] If it is detected that the at least two synchronization threads have a deadlock risk during the execution of the target program, an error message is outputted and the at least two synchronization threads are terminated, thereby effectively reducing the target program from being in a permanent suspended state at the GPU hardware level due to a deadlock. That is, through the synchronization detection within the thread block, it can be effectively detected whether all synchronization threads within the thread block have reached the same synchronization point, thereby detecting a deadlock scenario in which part of the synchronization threads within the thread block have returned or exited, or detecting a deadlock scenario in which part of the synchronization threads within the thread block are waiting at different synchronization points. Therefore, it can be detected whether a potential deadlock risk caused by a synchronization instruction occurs in each synchronization thread within the thread block during the execution of the target program, and the risk of false positives and / or false negatives of the deadlock risk can be reduced, thereby improving the detection accuracy of the deadlock risk.

[0067] Figure 2 A schematic flowchart of the synchronization detection within a thread block is provided for the embodiments of the present application. As shown in Figure 2 the above, it can include the following steps: Step 201: detecting that a synchronization thread within the thread block reaches a synchronization point, setting the execution state of the synchronization thread to a state of waiting at the synchronization point.

[0068] Since the stub code is inserted in advance at the synchronization point, after the synchronization thread reaches the synchronization point, the stub code is called, and the execution state of the synchronization thread is set to a state of waiting at the synchronization point. The execution state of the synchronization point can be set to the synchronization point ID of the synchronization point, to indicate that the execution state of the synchronization thread is in a state of waiting at the synchronization point.

[0069] Step 202: determining whether all synchronization threads within the thread block reach the synchronization point.

[0070] If yes, step 303 is executed; otherwise, step 304 is executed.

[0071] Step 203: executing the synchronization instruction, and all synchronization threads within the thread block pass through the synchronization point, and the execution state of all synchronization threads is reset to an executing state.

[0072] If the execution state of all synchronization threads is determined to be in a state of waiting at the synchronization point, it is considered that the execution state of all synchronization threads is consistent, and therefore it can be determined that there is no risk of deadlock, and the synchronization instruction_syncthreads() can be executed at the synchronization point to ensure the execution rhythm and cooperative processing of the synchronization threads within the thread block, and then all synchronization threads can continue to execute.

[0073] The execution state of all synchronization threads is reset to an executing state, for example, the execution state of all synchronization threads is reset to 0.

[0074] Step 204: detecting whether there is a synchronization thread within the thread block whose execution state is in a state of waiting at another synchronization point or a returned state.

[0075] Since the stub code is inserted in advance at the other synchronization point, after the synchronization thread reaches the other synchronization point, the stub code is called, and the execution state of the synchronization thread is set to a state of waiting at the other synchronization point, for example, the other synchronization point ID. The return statement is also pre-inserted with stub code, so when the synchronization thread executes the return statement, the stub code is called, and the execution state of the synchronization thread is set to a returned state (for example, the execution state is -1).

[0076] For example, if there is a synchronization thread within the thread block whose execution state is the other synchronization point ID, or a synchronization thread whose execution state is -1, it is determined that the execution state of the synchronization thread at the current synchronization point within the thread block does not meet the consistency requirement, and step 305 is executed.

[0077] Step 205: outputting error information and terminating all synchronization threads.

[0078] If the execution state of the partial synchronization threads is detected to be in a state of waiting at the synchronization point, and the execution state of the partial synchronization threads is in a state of waiting at other synchronization points or a returned state, it is determined that the synchronization threads have a risk of deadlock during execution of the target program, and thus error information is output and at least two synchronization threads are terminated, thereby effectively reducing the risk of the target program being suspended permanently at the GPU hardware level due to deadlock.

[0079] In another embodiment, taking the intra-grid synchronization point (for example, __syncblocks()) as an example, if the at least two synchronization threads are intra-grid synchronization threads, the execution states of the at least two synchronization threads at the same synchronization point are detected to determine whether they meet a preset consistency requirement, including: if the execution states of the at least two synchronization threads are detected to be waiting at the same synchronization point, it is determined that the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement; if the execution states of the partial synchronization threads are detected to be waiting at the synchronization point, and the execution states of the partial synchronization threads are detected to be returned, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

[0080] If the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement, it can be determined that the at least two synchronization threads do not have a risk of deadlock during execution of the target program, and the at least two synchronization threads can continue to execute. If the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement, it can be determined that the at least two synchronization threads have a risk of deadlock during execution of the target program, and an exception handling process can be performed, for example, error information is output and the at least two synchronization threads are terminated.

[0081] If the at least two synchronization threads are detected to have a risk of deadlock during execution of the target program, error information is output and the at least two synchronization threads are terminated, thereby effectively reducing the risk of the target program being suspended permanently at the GPU hardware level due to deadlock. That is, through intra-grid synchronization detection, it can be effectively detected whether all synchronization threads in the grid have reached the same synchronization point, thereby detecting a deadlock scenario in which partial synchronization threads in the grid have returned or exited, and thus it can be detected whether potential deadlock risks caused by synchronization instructions occur in the execution of the target program by the synchronization threads in the grid, and the risk of false positives and / or false negatives of the deadlock risks can be reduced, thereby improving the detection accuracy of the deadlock risks.

[0082] Optionally, the different synchronization points in the embodiments of the present application can refer to the synchronization points in the thread blocks and the synchronization points in the grids. The synchronization in the thread blocks is smaller in range than the synchronization in the grids, and thus, when the synchronization in the grids is performed, if the synchronization points in the thread blocks and the synchronization points in the grids exist simultaneously, the following can be allowed: when the synchronization points in the thread blocks are in front of the synchronization points in the grids, the synchronization threads can be allowed to execute the synchronization in the thread blocks first and then reach the synchronization points in the grids. That is, when the synchronization in the grids is performed, the execution state of the synchronization threads caused by the execution of the synchronization in the thread blocks can be allowed to be inconsistent.

[0083] When the synchronization points in the grids are in front of the synchronization points in the thread blocks, the synchronization threads can first perform the synchronization in the synchronization points in the grids, and then the synchronization threads that need to perform the synchronization in the thread blocks perform the synchronization in the synchronization points in the thread blocks.

[0084] That is, when the large-range synchronization and the small-range synchronization exist simultaneously, if the large-range synchronization is performed first and then the small-range synchronization is performed, all the synchronization threads are required to perform the large-range synchronization first, and then the synchronization threads that need to perform the small-range synchronization perform the small-range synchronization; if the small-range synchronization is performed first and then the large-range synchronization is performed, only the synchronization threads that need to perform the small-range synchronization perform the small-range synchronization, and other synchronization threads are not limited. Thus, when the synchronization in the grids is performed, the deadlock problem caused by the different synchronization points does not exist, that is, when the synchronization in the grids is performed, the different synchronization points are allowed.

[0085] Figure 3 A schematic flowchart of the synchronization detection in the grids provided by the embodiments of the present application is shown in FIG. 3. As shown in FIG. 3, the synchronization detection in the grids can include the following steps. Figure 3 Step 301: When it is detected that the synchronization threads in the grids reach the synchronization points, the execution state of the synchronization threads is set to the state of waiting at the synchronization points.

[0086] Because the stub code is inserted in the synchronization points in advance, when the synchronization threads reach the synchronization points, the stub code is called, and the execution state of the synchronization threads is set to the state of waiting at the synchronization points. The execution state of the synchronization points can be set to the synchronization point ID of the synchronization points, to indicate that the execution state of the synchronization threads is the state of waiting at the synchronization points.

[0087] Step 302: Whether all the synchronization threads in the grids reach the synchronization points is determined.

[0088] If yes, step 403 is performed; otherwise, step 404 is performed.

[0089] ​​Step 303: execute the synchronization instruction, all the synchronization threads in the grid pass through the synchronization point, and the execution states of all the synchronization threads are reset to the state of being executed.

[0090] If the execution states of all the synchronization threads are detected to be the state of waiting at the synchronization point, it is considered that the execution states of all the synchronization threads are consistent, and thus it can be determined that there is no risk of deadlock, and the synchronization instruction __syncblocks() can be executed at the synchronization point to ensure the execution rhythm and cooperative processing of the synchronization threads in the grid, and then all the synchronization threads can continue to execute.

[0091] The execution states of all the synchronization threads are reset to the state of being executed, for example, the execution states of all the synchronization threads can be reset to 0.

[0092] Step 304: detect whether there is a synchronization thread in the grid whose execution state is the state of having returned.

[0093] Because the stub code is inserted in advance at other synchronization points, when the synchronization thread reaches the other synchronization point, the stub code is called, and the execution state of the synchronization thread is set to the state of waiting at the other synchronization point, for example, the ID of the other synchronization point. The return statement is also inserted with stub code in advance, and thus when the synchronization thread executes the return statement, the stub code is called, and the execution state of the synchronization thread is set to the state of having returned (for example, the execution state is -1).

[0094] For example, if there is a synchronization thread in the grid whose execution state is -1, it is determined that the execution states of the synchronization threads in the grid at the current synchronization point do not meet the consistency requirement, and step 405 is executed.

[0095] Step 305: output error information and terminate all the synchronization threads.

[0096] If it is detected that part of the synchronization threads in the grid are in the state of waiting at the synchronization point, and part of the synchronization threads are in the state of having returned, it is determined that there is a risk of deadlock in the execution of the target program by the synchronization threads, and thus error information needs to be output and at least two synchronization threads need to be terminated, so as to effectively reduce the permanent suspension of the target program at the GPU hardware level caused by the deadlock.

[0097] In another embodiment, when the return statement is detected, the execution state of the synchronization thread can be set to the state of having returned before the return statement is executed, and then the original return statement is executed. In this way, the synchronization thread that executes the return statement can be marked as the state of having returned, so as to ensure that the deadlock scenario caused by early return can be detected.

[0098] The application obtains execution states of at least two synchronization threads by using the inserted stub code at the preset synchronization points (including the synchronization points within a thread block and the synchronization points within a grid) and the return statement during execution of the target program, and then determines whether the execution states of the synchronization threads reach an agreement at the same synchronization point by comparing the execution states of the synchronization threads, so as to identify potential deadlock risks. Next, a scheme for obtaining the execution states of the at least two synchronization threads is introduced.

[0099] In an embodiment, the execution states of the at least two synchronization threads are obtained by using the inserted stub code at the preset synchronization points and the return statement, including: writing the execution states of the synchronization threads into the global memory of the graphics processing unit in the form of an array by using the inserted stub code at the preset synchronization points and the return statement; and detecting whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads according to the execution states of the at least two synchronization threads, including: reading the execution states of the at least two synchronization threads from the global memory of the graphics processing unit to detect whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads.

[0100] To implement the deadlock detection mechanism, each synchronization thread in the embodiment can maintain an execution state information accessible by all the synchronization threads at runtime. After the execution states of the synchronization threads are monitored by using the inserted stub code at the preset synchronization points and the return statement, the execution states of the synchronization threads can be written into the global memory of the graphics processing unit in the form of an array, so that the execution states of the synchronization threads can be accessed by each other, thereby optimizing the communication efficiency between the synchronization threads.

[0101] Correspondingly, when detecting whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads, the execution states of the at least two synchronization threads can be read from the global memory of the graphics processing unit, so as to determine whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads, thereby improving the efficiency of detecting the deadlock risk.

[0102] The execution states of the synchronization threads can be written into the global memory of the graphics processing unit in the form of a single-flag array or a double-flag array. The size of the array can be determined according to the number of the synchronization threads, and the synchronization threads can be identified by an index (or a subscript) in the array. The value of the index identifying the synchronization threads can be the ID of the synchronization thread. Next, the execution states of the synchronization threads are written into the global memory of the graphics processing unit in the form of a single-flag array and a double-flag array, respectively.

[0103] In an embodiment, the execution state of each synchronization thread is written in the global memory of the graphics processing unit in the form of a single flag array. That is, the execution state of each synchronization thread is written in the global memory of the graphics processing unit in the form of an array, including: writing the execution state of the synchronization thread in the global memory of the graphics processing unit in the form of a single flag array, each element in the single flag array indicating that the execution is being performed, waiting at a synchronization point, or has returned, and the index in the single flag array is used to identify the synchronization thread.

[0104] For example, the single flag array can be state[thread_id], where thread_id is an index used to identify the synchronization thread, and the value of thread_id can be the ID of the synchronization thread, and the corresponding element of thread_id in the array is represented as the value of state[thread_id], indicating the execution state of the corresponding synchronization thread. The execution state of the synchronization thread can be stored in the global memory of the graphics processing unit in the form of an integer, for example, state[T1]=0 indicates that the T1 thread is being executed, state[T1]=-1 indicates that the T1 thread has returned or exited, and state[T1]= synchronization point ID indicates that the T1 thread is waiting at a specific synchronization point, such as state[T1]=1 indicating that the T1 thread is waiting at a synchronization point within a thread block, and state[T1]=2 indicating that the T1 thread is waiting at a synchronization point within a grid.

[0105] Writing the execution state of the synchronization thread in the global memory of the graphics processing unit in the form of a single flag array can greatly improve the space efficiency in a large-scale synchronization thread scenario, and the single flag array is easy to understand and maintain, which can improve the efficiency of deadlock detection.

[0106] Taking two synchronization threads T0 and T1 executing a target program as an example, the execution state is in the form of a single flag array. T0 and T1 reach synchronization point 1, the synchronization point ID of synchronization point 1 is 1, and state[T0]=state[T1]=1 is set; T0 and T1 pass through synchronization point 1, and state[T0]=state[T1]=0 is reset; T0 quickly reaches synchronization point 2, the synchronization point ID of synchronization point 2 is 2, state[T0]=2 is set, and the execution state of T1 can be checked; the execution state of T1 is state[T1]=0, indicating that T1 thread is being executed, and T0 waits at synchronization point 2 for T1 to reach synchronization point 2. Therefore, it can be determined that T0 and T1 do not have a deadlock risk in the process of executing the target program.

[0107] It can be seen that by inserting the stub code at the preset synchronization point and the return statement, and using the single flag array to identify the execution state of the synchronization thread, the deadlock problem caused by inconsistent synchronization mechanisms in the arbitrary branch divergence scenario can be detected.

[0108] However, by using the single flag array to identify the execution state of the synchronization thread, there is still a potential risk, that is, false positives of the deadlock may be caused by the race condition of the state data. Figure 4 A thread synchronization timing diagram is provided for the embodiments of the present application. Figure 4 In the example of the two synchronization threads T0 and T1 executing the target program, the execution state is in the form of a single flag array. T0 and T1 reach synchronization point 1, the synchronization point ID of synchronization point 1 is 1, state[T0] = state[T1] = 1 is set; T0 and T1 pass through synchronization point 1, and state[T0] = state[T1] = 0 is reset; T0 quickly reaches synchronization point 2, the synchronization point ID of synchronization point 2 is 2, state[T0] = 2 is set and the execution state of T1 can be detected. However, since the read and write operations of the execution state of the synchronization thread are asynchronous, when reading the execution state of T1, the old execution state that has not been reset may be captured due to the invisible execution state of T1 after switching, or the reset operation of the execution state may be delayed due to unpredictable GPU thread scheduling. Therefore, after T0 quickly reaches synchronization point 2 and sets state[T0] = 2, the execution state of T1 may be read as state[T1] = 1, which may mistakenly believe that T1 is waiting at synchronization point 1, thereby causing false positives of the deadlock.

[0109] Therefore, in order to solve the problem of false positives of the deadlock caused by the race condition of the state data, the execution state of each synchronization thread can be written into the global memory of the graphics processing unit in the form of a double flag array.

[0110] In another embodiment, the execution state of each synchronization thread is written into the global memory of the graphics processing unit in the form of an array, including: writing the execution state of the synchronization thread into the global memory of the graphics processing unit in the form of a double flag array, each element in the double flag array being used to indicate that it is being executed, waiting at a synchronization point, or has returned, the double flag array including a first index and a second index pointing to the same element, the first index being used to switch two state flags to identify the currently used state array, and the second index being used to identify the synchronization thread, wherein the currently used state flag is switched through the first index after the synchronization thread passes through the synchronization point; obtaining the execution state of at least two synchronization threads, including: obtaining the element pointed to by the at least two synchronization threads at the same first index.

[0111] For the form of the double-flag array, each synchronization thread corresponds to two state flags, and a two-dimensional state flag array is formed by the two state flags, that is, a double-flag array. For example, the form of the double-flag array can be state[flag][thread_id], where the second index thread_id identifies the synchronization thread, and the value of thread_id can be the ID of the synchronization thread; the first index flag corresponds to two values, 0 and 1 respectively, and the two state flags corresponding to the synchronization thread identified by thread_id are state[0][thread_id] and state[1][thread_id] respectively, that is, the synchronization thread identified by thread_id can be considered to maintain two state arrays, state[0][thread_id] and state[1][thread_id] respectively. The element in the double-flag array is the value of the array, that is, the value of state[flag][thread_id], which indicates the execution state of the corresponding synchronization thread.

[0112] In the initial state, state[0][thread_id]= state[1][thread_id]= 0. After the synchronization thread identified by thread_id reaches the synchronization point (for example, the ID of the synchronization point is 1), state[0][thread_id]=1 is used; after the synchronization thread identified by thread_id passes through the synchronization point, flag=1-flag is switched, and state[1][thread_id]=0 is used. That is, after the synchronization thread passes through the synchronization point, the value of flag is switched to realize the switching of the state flag of the synchronization thread, that is, the state array currently used by the synchronization thread identified by thread_id is switched from state[0][thread_id] to state[1][thread_id].

[0113] Figure 5 Another thread synchronization timing diagram provided by the embodiments of the present application. In Figure 5Still taking the example of executing the target program by two synchronization threads T0 and T1, the execution state adopts the form of the double-flag array. T0 and T1 reach the synchronization point 1, the synchronization point ID of the synchronization point 1 is 1, state[0][T0]= state[0][T1]= 1 is set; after T0 and T1 pass through the synchronization point 1, the switch flag = 1 – flag, then state[1][T0]= state[1][T1]= 0; T0 quickly reaches the synchronization point 2, the synchronization point ID of the synchronization point 2 is 2, state[1][T0]= 2 is set, and the execution state of T1 can be checked; the execution state of T1 is state[1][T1]= 0, indicating that the TI thread has passed through the synchronization point 1 and is executing, and T0 waits for T1 to reach the synchronization point 2 at the synchronization point 2; after T1 reaches the synchronization point 2, state[1][T1]= 2 is set. Since state[1][T0]= state[1][T1]= 2, the execution state of the synchronization thread is identified by the form of the double-flag array, which can ensure that the resetting of the execution state of the synchronization thread is visible to the subsequent detection, thereby solving the problem of false positives of the deadlock caused by the existence of the competition condition of the state data of the single-flag array, and improving the accuracy of detecting the synchronization deadlock.

[0114] That is, the first index in the double-flag array can be used to identify the state array currently used by the synchronization thread by switching the two state flags of the synchronization thread. Since each synchronization thread corresponds to two state flags, that is, each synchronization thread maintains two state arrays, by using the two state arrays in this rolling manner, it can be ensured that the state switching of the synchronization thread after passing through the synchronization point is visible to the subsequent check, and the uncertainty of accessing the global memory of the graphics processing unit is reduced, thus the problem of false positives of the deadlock caused by the existence of the competition condition of the state data of the single-flag array can be solved.

[0115] The execution state of the synchronization thread is written into the global memory of the graphics processing unit in the form of a double-flag array, so that when the execution states of at least two synchronization threads are obtained, the elements pointed to by at least two synchronization threads at the same time can be obtained, and in the scenario of multi-stage synchronization, the accuracy of deadlock detection can be greatly improved, and the false positive of deadlock can be reduced.

[0116] It should be noted that the form of a single flag array can also be state[flag][thread_id], where the index flag corresponds to a numerical value, that is, when the execution status of the synchronous thread is written into the global memory of the graphics processing unit in the form of a single flag array, each synchronous thread corresponds to a state flag. Since there is only one flag value, there is no need to switch the state flag. Therefore, in order to simplify the form of the single flag array, the single flag array can omit the flag and only use state[thread_id] to represent it.

[0117] In summary, the thread synchronization exception handling method proposed in this application uses runtime checks to overcome the limitations of static checks, including the following methods: (1) Deadlock detection for dynamic branch divergence: By monitoring the execution status of threads while the program is running, synchronization deadlock problems in branch divergence can be detected in real time, such as some threads skipping synchronization or exiting early.

[0118] (2) Deadlock identification for complex synchronization point combinations: When the program is running, the waiting status of threads at different synchronization points can be checked to identify deadlock problems caused by mutual waiting due to synchronization point mismatch.

[0119] (3) For cross-platform adaptability: Design a general runtime checking mechanism that can adapt to the synchronization semantics and hardware limitations of multiple GPU architectures.

[0120] (4) To reduce false positives and improve diagnostic capabilities: reduce the false positive rate by checking the status of the program during runtime, and provide detailed deadlock causes (such as thread status, synchronization point ID) to facilitate developers to fix them.

[0121] (5) Handling of runtime data contention: Introducing a rolling state array in the program runtime check can eliminate data contention in the thread state check and ensure the accuracy of the detection results.

[0122] (6) Runtime checking for low performance overhead: By inserting the intermediate representation (IR) layer during the compilation phase and optimizing the runtime checking logic, the impact on program performance can be minimized, making it widely applicable to scenarios such as high-performance computing, graphics rendering, and embedded GPUs.

[0123] In other words, the thread synchronization exception handling method provided by this application utilizes runtime checks to capture runtime branch conditions and thread scheduling behavior, accurately detecting dynamic deadlock scenarios. By providing runtime information such as thread status and synchronization point IDs, it enhances error diagnosis capabilities and improves debugging efficiency. By abstracting the checking logic of synchronization instructions, it adapts to the hardware semantics of different GPU architectures and ensures cross-platform reliability. Therefore, this application not only identifies potential deadlock risks but also reduces the risk of false positives and / or false negatives, thereby improving the accuracy of deadlock risk detection.

[0124] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0125] According to another embodiment, a thread synchronization exception handling device is provided. Figure 6 This is a schematic block diagram of a thread synchronization exception handling device provided in an embodiment of the present application. Figure 6 As shown, the thread synchronization exception handling device 600 mainly includes: an acquisition module 601 and a detection module 602. The main functions of each component unit are as follows: The acquisition module 601 is configured to acquire the execution status of at least two synchronous threads by using stub codes pre-inserted at preset synchronization points and return statements during the execution of the target program.

[0126] The detection module 602 is configured to detect whether there is a deadlock risk in the process of executing the target program between the at least two synchronous threads according to the execution status of the at least two synchronous threads.

[0127] As one of the feasible ways, the acquisition module 601 can be specifically configured as follows: using the stub code pre-inserted at the preset synchronization point and return statement, the execution status of each synchronous thread is written into the global memory of the graphics processing unit in the form of an array; the detection module 602 can be specifically configured as follows: reading the execution status of at least two synchronous threads from the global memory of the graphics processing unit to detect whether there is a deadlock risk between the at least two synchronous threads during the execution of the target program.

[0128] As one of the implementable manners, the obtaining module 601, when writing the execution states of the synchronization threads into the global memory of the graphics processing unit in the form of an array, can be specifically configured to write the execution states of the synchronization threads into the global memory of the graphics processing unit in the form of a single-flag-bit array, each element in the single-flag-bit array being used to indicate being executed, waiting at a synchronization point, or having returned, and the index in the single-flag-bit array being used to identify the synchronization thread.

[0129] As another implementable manner, the obtaining module 601, when writing the execution states of the synchronization threads into the global memory of the graphics processing unit in the form of an array, can be specifically configured to write the execution states of the synchronization threads into the global memory of the graphics processing unit in the form of a double-flag-bit array, each element in the double-flag-bit array being used to indicate being executed, waiting at a synchronization point, or having returned, and the double-flag-bit array including a first index and a second index pointing to the same element, the first index being used to switch two state flags to identify a currently used state array, and the second index being used to identify the synchronization thread, wherein the currently used state flag is switched through the first index after the synchronization thread passes through the synchronization point; and when obtaining the execution states of the at least two synchronization threads, the obtaining module 601 can be specifically configured to obtain the elements pointed to by the at least two synchronization threads when the first indexes are the same.

[0130] As one of the implementable manners, the detecting module 602 is specifically configured to detect, according to the execution states of the at least two synchronization threads, whether the execution states of the at least two synchronization threads at the same synchronization point meet a preset consistency requirement, and determine that there is a deadlock risk in the execution of the target program by the at least two synchronization threads if the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

[0131] As one of the implementable manners, the at least two synchronization threads are synchronization threads in a thread block; and when detecting whether the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement, the detecting module 602 can be specifically configured to: if it is detected that the execution states of the at least two synchronization threads are all waiting at the same synchronization point, determine that the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement; if it is detected that the execution states of the at least two synchronization threads are waiting at different synchronization points, determine that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement; and if it is detected that, among the at least two synchronization threads, the execution states of some synchronization threads are waiting at a synchronization point and the execution states of some synchronization threads have returned, determine that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

[0132] As another implementable manner, the at least two synchronization threads are synchronization threads in the grid; when detecting whether the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement, the detection module 602 can be specifically configured to: if it is detected that the execution states of the at least two synchronization threads are all waiting at the same synchronization point, it is determined that the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement; if it is detected that, among the at least two synchronization threads, the execution state of part of the synchronization threads is waiting at the synchronization point and the execution state of part of the synchronization threads is returned, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

[0133] Further, the detection module 602 is further configured to: if it is detected that there is a deadlock risk in the execution of the target program by the at least two synchronization threads, output error information and terminate the at least two synchronization threads.

[0134] Further, the thread synchronization exception processing apparatus 600 further comprises an insertion module (not shown in the figure) configured to: before executing the target program, compile source code of the target program into an intermediate representation, insert a stake code at a preset synchronization point and a return statement based on the intermediate representation; and convert the intermediate representation into machine code to execute the target program.

[0135] Each of the embodiments in the specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other. Each embodiment focuses on the difference from other embodiments. Especially, for the system or device embodiments, since they are basically similar to the method embodiments, they are described more simply, and the related parts can be referred to the part of the method embodiments. The system and device embodiments described above are only illustrative, and the units described as separate components can be or can not be physically separated, and the components displayed as units can be or can not be physical units, that is, they can be located in one place or distributed on multiple network units. According to actual needs, part or all of the modules can be selected to achieve the purpose of the embodiment. Those skilled in the art can understand and implement it without creative labor.

[0136] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0137] In addition, the application further provides an electronic device, comprising: one or more processors; and a memory associated with the one or more processors, the memory being configured to store program instructions, which, when executed by the one or more processors, implement the steps of the thread synchronization exception handling method in any one of the preceding method embodiments.

[0138] wherein, Figure 7 a schematic block diagram of the electronic device provided by the application. Figure 7 The electronic device 700 shown (which can be a computer device in particular) comprises a memory 701, a processor 702, a communication interface 703, and a bus 704. The memory 701, the processor 702, and the communication interface 703 are communicatively connected to each other through the bus 704.

[0139] The memory 701 can be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 701 can store a program, and when the program stored in the memory 701 is executed by the processor 702, the processor 702 and the communication interface 703 are configured to implement each step of the thread synchronization exception handling method of the electronic device or the thread synchronization exception handling apparatus of the application.

[0140] The processor 702 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), or one or more integrated circuits, configured to execute related programs to implement the functions required by the units in the electronic device or the thread synchronization exception handling apparatus of the application.

[0141] The processor 702 can also be an integrated circuit chip having signal processing capability. In implementation, the various steps of the thread synchronization exception handling method of the present application can be completed by integrated logic circuits or instructions in the form of software in the processor 702. The processor 702 described above can also be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The various methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as a hardware code processor to execute, or be executed by a combination of hardware and software modules in the code processor. The software module can be located in a random access memory, a flash memory, a read only memory, a programmable read only memory or an electrically erasable programmable memory, a register, or other mature storage medium in the art. The storage medium is located in the memory 701, and the processor 702 reads the information in the memory 701, and combines the hardware to complete the functions required by the units included in the thread synchronization exception handling device of the embodiments of the present application, or executes the thread synchronization exception handling method of the method embodiments of the present application.

[0142] The communication interface 703 uses a transceiver device such as but not limited to a transceiver to realize the communication between the electronic device 700 and other devices or communication networks. For example, the sensor data can be obtained through the communication interface 703.

[0143] The bus 704 can include a path for transmitting information between various components (for example, the memory 701, the processor 702, the communication interface 703) of the electronic device 700.

[0144] It should be noted that although Figure 7 The electronic device 700 shown only shows the memory, the processor, the communication interface, but in the specific implementation process, those skilled in the art should understand that the electronic device 700 also includes other devices necessary for normal operation. At the same time, according to the specific needs, those skilled in the art should understand that the electronic device 700 can also include hardware devices for realizing other additional functions. In addition, those skilled in the art should understand that the electronic device 700 can also only include the devices necessary for the embodiments of the present application, and does not have to include all the devices shown in the above. Figure 7

[0145] ​The application also provides a computer program product comprising a computer program which, when executed, implements the steps of the thread synchronization exception handling method of any of the preceding method embodiments.

[0146] The computer program product can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++, etc., and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device or entirely on the remote computing device or server.

[0147] The application also provides a computer readable storage medium having computer program instructions stored thereon, which, when executed by a processor, cause the processor to perform each step of the thread synchronization exception handling method provided by each embodiment of the application.

[0148] The computer readable storage medium can be any combination of one or more non-transitory media. The non-transitory medium can be a non-transitory signal medium or a non-transitory storage medium. The non-transitory storage medium can include, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the above. More specific examples (a non-exhaustive list) of the non-transitory storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0149] Those skilled in the art can clearly understand that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.

[0150] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the preceding method embodiments, which will not be described here.

[0151] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. The division of the units is merely logical function division. There can be another division manner for the actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0152] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0153] In addition, the functional units in the various embodiments of the present application can be integrated in a similar area division unit, or each unit can be physically present alone, or two or more units can be integrated in one unit.

[0154] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk.

[0155] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A thread synchronization exception handling method, characterized in that: The method comprises the following steps: During execution of a target program, execution states of at least two synchronization threads are obtained by using a pre-inserted probe code at a preset synchronization point and a return statement; According to the execution states of the at least two synchronization threads, whether there is a deadlock risk in execution of the target program by the at least two synchronization threads is detected.

2. The abnormality processing method according to claim 1, characterized by, The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps:

3. The abnormality processing method according to claim 2, characterized by, The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps:

4. The abnormality processing method according to claim 2, characterized by, The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps:

5. The abnormality processing method according to claim 1, characterized by, The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps:

6. The abnormality processing method according to claim 5, characterized by, The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the return statement, which comprises the following steps: The execution states of the at least two synchronization threads are obtained by using the pre-inserted probe code at the preset synchronization point and the If it is detected that the execution states of the at least two synchronization threads are all waiting at the same synchronization point, it is determined that the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement. If it is detected that the execution states of the at least two synchronization threads are waiting at different synchronization points, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement. If it is detected that the execution states of some of the at least two synchronization threads are waiting at the synchronization point and the execution states of some of the at least two synchronization threads have returned, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

7. The abnormality processing method according to claim 5, characterized by, The at least two synchronization threads are synchronization threads in a grid. The detection of whether the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement comprises: If it is detected that the execution states of the at least two synchronization threads are all waiting at the same synchronization point, it is determined that the execution states of the at least two synchronization threads at the same synchronization point meet the preset consistency requirement. If it is detected that the execution states of some of the at least two synchronization threads are waiting at the synchronization point and the execution states of some of the at least two synchronization threads have returned, it is determined that the execution states of the at least two synchronization threads at the same synchronization point do not meet the preset consistency requirement.

8. The abnormality processing method according to any one of claims 1 to 7, characterized by, Further comprising: If it is detected that there is a deadlock risk in the execution of the target program by the at least two synchronization threads, error information is output and the execution of the target program by the at least two synchronization threads is terminated.

9. The abnormality processing method according to any one of claims 1 to 7, characterized by, Before the execution of the target program, the exception handling method further comprises: compiling a source code of the target program into an intermediate representation, and inserting a stake code at the preset synchronization point and the return statement based on the intermediate representation; converting the intermediate representation into machine code to execute the target program.

10. An apparatus for handling exceptions in thread synchronization, characterized by Comprising: an acquisition module configured to acquire execution states of at least two synchronization threads by using a stake code inserted in advance at a preset synchronization point and a return statement during execution of a target program; a detection module configured to detect whether there is a deadlock risk in the execution of the target program by the at least two synchronization threads according to the execution states of the at least two synchronization threads.

11. An electronic device, comprising: Comprising: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, the program instructions being read and executed by the one or more processors to perform the exception handling method of thread synchronization according to any one of claims 1 to 9.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed to implement the exception handling method of thread synchronization according to any one of claims 1 to 9.

13. A computer program product comprising a computer program, characterized in that, The computer program is executed to implement the exception handling method of thread synchronization according to any one of claims 1 to 9.

Images