Positioning method for program jamming caused by deadlock of C # synchronous lock

Abstract

The invention discloses a positioning method for program jamming caused by deadlock of a C # synchronous lock, and relates to the field of computer application, comprising the following steps: S1, defining a TraceLock for tracking class object information of the lock; s2, creating a TraceLock type object when an external thread is locked, and adding one to the object count of the number index corresponding to the internal cache array; s3, when the external thread uses the release lock, subtracting one from the object count of the number index corresponding to the internal cache array; s4, a monitoring thread in the TrackLock monitors the array in a timed mode; and S5, when thread deadlock occurs, the user determines the numbers of which two locks are not unlocked for a long time through the printed log, and the position for calling the synchronous lock can be positioned through the two numbers. According to the positioning method for program jamming caused by deadlock of the C # synchronous lock, when the program uses the synchronous lock to realize thread synchronization, if deadlock occurs, the method can be used for quickly positioning the deadlock code position through a log.

Description

Technical Field

[0001] The present invention relates to the field of computer applications, and in particular to a method for locating a program stuck due to a C# synchronous deadlock. Background Art

[0002] The current software functions are becoming more and more complex. In order to improve the execution efficiency of the software, the use of multi-threading is a very common technical means. When multiple threads in the program are executed concurrently and multiple threads read and write the same resource, dirty reads and misreads are prone to occur. In order to prevent this from happening, synchronization locks came into being. Each thread locks the resource before accessing it. If a thread locks successfully, it means that it has obtained the permission to read and write this resource, and other threads cannot lock it. After it has finished reading and writing, it releases the lock, and other threads can lock it successfully.

[0003] Although the synchronization lock technology solves the problems of dirty reading and misreading of the same resource, it also brings a new potential problem, that is, the deadlock of the synchronization lock. For example, if there are two shared resources, two synchronization locks are required. For example, there are two threads T1 and T2, two shared resources S1 and S2, and two synchronization locks L1 and L2. If thread T1 first locks S1 with L1, and thread T2 locks S2 with L2, then T1 wants to access S2 again, but S2 has been locked by T2, it can only wait. Similarly, T2 also wants to use S1, but S1 has been locked by T1, it can only wait. Therefore, T1 and T2 are waiting for each other to release the required resource locks, causing the program to freeze.

[0004] Deadlock problems are not inevitable and are relatively hidden, so once they occur, they are difficult to locate. This is especially true when many threads are opened up in the program and a large number of synchronization locks are used, making it even more difficult to troubleshoot.

[0005] Therefore, it is necessary to propose a positioning method based on C# synchronous lock deadlock that causes program jam to solve the above problem. Summary of the invention

[0006] The main purpose of the present invention is to provide a positioning method based on C# synchronous lock deadlock causing program jamming, which can effectively solve the problems in the background technology.

[0007] To achieve the above object, the technical solution adopted by the present invention is:

[0008] A method for locating a program stuck due to a C# synchronous lock deadlock, including the following steps:

[0009] S1: Define a TraceLock class object to track lock information, which contains a static lock information array and an independent thread that monitors the state of objects in the array;

[0010] S2: When the external thread locks, it creates a TraceLock class object, passes in the locked object and the lock number, and when the lock is successful, increases the object count of the corresponding number index in the internal cache array by one, and then the thread continues to execute, otherwise the thread is blocked and waiting;

[0011] S3: When the external thread has finished using the lock, it will reduce the object count of the corresponding number index in the internal cache array by one, and clear the timer at the same time;

[0012] S4: The monitoring thread inside TrackLock monitors the array regularly. When it finds that the count of an object is greater than 0 and the count exceeds a set time, it prints out the lock number that has not been released for a long time.

[0013] S5: When a thread deadlock occurs, the user can use the printed log to determine which two lock numbers have not been unlocked for a long time. The two numbers can be used to locate the location where the synchronization lock is called, and the code can be corrected based on this.

[0014] S6: Use the Visual Studio debugger to locate, including the following steps:

[0015] S601: Reproduce the deadlock scenario, reproduce the deadlock problem, and trigger the program to enter the deadlock state through specific input and operation sequences;

[0016] S602: Start debugging. In Visual Studio, run the program and wait for a deadlock to occur. When the program is stuck, enter the debugging mode.

[0017] S603: Check the thread window, open the thread window in the debug menu, and observe the status of all running threads. In the deadlock state, the thread is in a waiting state;

[0018] S604: Check the call stack. For threads in the waiting state, right-click the thread and select Switch to Frame, Display Call Stack. Based on this, check the method currently being executed by each thread and the location where the lock is acquired. If the thread is executing a method containing a lock statement and is always in the state of waiting for the lock to be released, it is determined to be the cause of the deadlock.

[0019] S7: Use the analysis tool, including the following steps:

[0020] S701: Install and configure tools, install ANTSPerformanceProfiler, and configure it to analyze C# programs;

[0021] S702: Run the analysis, start ANTSPerformanceProfiler and reproduce the deadlock scenario. The tool will collect data in the background, including thread execution time and method call frequency;

[0022] S703: Check the thread behavior and lock contention. In the report of the analysis tool, find the part about thread synchronization and lock.

[0023] S8: Review the code and carefully check all places where the lock keyword is used in the code. When multiple lock statements are nested, observe the order in which they are acquired. If the acquisition order is different, it is considered a deadlock.

[0024] Preferably, in S2, the number is used to locate the code position, and the number cannot be repeated.

[0025] Preferably, in S5, the step of causing thread deadlock includes the following steps:

[0026] S501: Thread 1 creates a TrackLock, the lock object is obj1, and the number is 0. At this time, the lock object obj1 is idle, so the lock is successful, and the LockInfo with array index 0 increases the count by 1;

[0027] S502: Thread 2 creates a TrackLock, the lock object is obj2, and the number is 5. At this time, the lock object obj2 is idle, so the lock is successful, and the LockInfo with array index 5 increases the count by 1;

[0028] S503: Thread 1 creates another TrackLock, the lock object is obj2, and the number is 3, but obj2 has been locked by Thread 2, so Thread 1 is blocked at this time;

[0029] S504: Process 2 creates another TrackLock, the lock object is obj1, the number is n, but obj1 has been locked by thread 1, so thread 2 is blocked at this time;

[0030] S505: After executing the above correction, threads 1 and 2 are deadlocked with each other, causing the program to freeze.

[0031] Preferably, in S1, the independent thread for monitoring the state of objects in the array includes the following operation steps:

[0032] S101: The thread first traverses the LockInfo array and takes out the first object;

[0033] S102: Check whether the count of the LockInfo object is greater than 0. If not, determine whether it is the last one in the array.

[0034] S103: Check whether the recorded time in LockInfo is greater than 15 seconds. If not, increase the timer and determine whether it is the last one in the array.

[0035] S104: If the LockInfo count is greater than 0 and the timer exceeds 15 seconds, it indicates that the lock is deadlocked, and the lock number in LockInfo is printed out;

[0036] S105: After checking the current LockInfo, confirm whether it is the last one in the array. If not, directly obtain the array to check the next LockInfo;

[0037] S106: If the array traversal is completed, wait for 3 seconds, then return to S101 and start traversing the array again.

[0038] Compared with the prior art, the present invention provides a method for locating a program stuck due to a C# synchronous lock, which has the following beneficial effects:

[0039] This method is based on the positioning method of the program stuck due to the deadlock of the C# synchronization lock. When the program uses the synchronization lock to achieve thread synchronization, if a deadlock occurs, this method can be used to quickly locate the code position where the deadlock occurs through the log. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0041] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, the present invention is further explained below in conjunction with specific implementation methods.

[0042] like Figure 1 As shown in the figure, a method for locating a program stuck due to a C# synchronous lock deadlock includes the following steps:

[0043] S1: Define a TraceLock class object to track lock information, which contains a static lock information array and an independent thread that monitors the state of objects in the array;

[0044] A separate thread that monitors the state of objects in an array consists of the following steps:

[0045] S101: The thread first traverses the LockInfo array and takes out the first object;

[0046] S102: Check whether the count of the LockInfo object is greater than 0. If not, determine whether it is the last one in the array.

[0047] S103: Check whether the recorded time in LockInfo is greater than 15 seconds. If not, increase the timer and determine whether it is the last one in the array.

[0048] S104: If the LockInfo count is greater than 0 and the timer exceeds 15 seconds, it indicates that the lock is deadlocked, and the lock number in LockInfo is printed out;

[0049] S105: After checking the current LockInfo, confirm whether it is the last one in the array. If not, directly obtain the array to check the next LockInfo;

[0050] S106: If the array traversal is completed, wait for 3 seconds, then return to S101 and start traversing the array again;

[0051] S2: When the external thread is locked, a TraceLock class object is created, and the locked object and the lock number are passed in. The number is used to locate the code position and the number cannot be repeated. When the lock is successful, the object count of the corresponding number index in the internal cache array is increased by one, and then the thread continues to execute, otherwise the thread is blocked and waiting;

[0052] S3: When the external thread has finished using the lock, it will reduce the object count of the corresponding number index in the internal cache array by one, and clear the timer at the same time;

[0053] S4: The monitoring thread inside TrackLock monitors the array regularly. When it finds that the count of an object is greater than 0 and the count exceeds a set time, it prints out the lock number that has not been released for a long time.

[0054] S5: When a thread deadlock occurs, the user can use the printed log to determine which two lock numbers have not been unlocked for a long time. The two numbers can be used to locate the location where the synchronization lock is called, and the code can be corrected based on this.

[0055] The steps for thread deadlock to occur include the following steps:

[0056] S501: Thread 1 creates a TrackLock, the lock object is obj1, and the number is 0. At this time, the lock object obj1 is idle, so the lock is successful, and the LockInfo with array index 0 increases the count by 1;

[0057] S502: Thread 2 creates a TrackLock, the lock object is obj2, and the number is 5. At this time, the lock object obj2 is idle, so the lock is successful, and the LockInfo with array index 5 increases the count by 1;

[0058] S503: Thread 1 creates another TrackLock, the lock object is obj2, and the number is 3, but obj2 has been locked by Thread 2, so Thread 1 is blocked at this time;

[0059] S504: Process 2 creates another TrackLock, the lock object is obj1, the number is n, but obj1 has been locked by thread 1, so thread 2 is blocked at this time;

[0060] S505: After executing the above correction, threads 1 and 2 are deadlocked with each other, causing the program to freeze;

[0061] S6: Use the Visual Studio debugger to locate, including the following steps:

[0062] S601: Reproduce the deadlock scenario, reproduce the deadlock problem, and trigger the program to enter the deadlock state through specific input and operation sequences;

[0063] S602: Start debugging. In Visual Studio, run the program and wait for a deadlock to occur. When the program is stuck, enter the debugging mode.

[0064] S603: Check the thread window, open the thread window in the debug menu, and observe the status of all running threads. In the deadlock state, the thread is in a waiting state;

[0065] S604: Check the call stack. For threads in the waiting state, right-click the thread and select Switch to Frame, Display Call Stack. Based on this, check the method currently being executed by each thread and the location where the lock is acquired. If the thread is executing a method containing a lock statement and is always in the state of waiting for the lock to be released, it is determined to be the cause of the deadlock.

[0066] S7: Use the analysis tool, including the following steps:

[0067] S701: Install and configure tools, install ANTSPerformanceProfiler, and configure it to analyze C# programs;

[0068] S702: Run the analysis, start ANTSPerformanceProfiler and reproduce the deadlock scenario. The tool will collect data in the background, including thread execution time and method call frequency;

[0069] S703: Check the thread behavior and lock contention. In the report of the analysis tool, find the part about thread synchronization and lock.

[0070] S8: Review the code and carefully check all places where the lock keyword is used in the code. When multiple lock statements are nested, observe the order in which they are acquired. If the acquisition order is different, it is considered a deadlock.

[0071] Specific coding implementation method:

[0072]

[0073]

[0074]

[0075]

[0076] The above shows and describes the basic principles and main features of the present invention and the advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A method for locating a program stuck due to a C# synchronous deadlock, characterized in that: The steps include: S1: Define a TraceLock class object to track lock information, which contains a static lock information array and an independent thread that monitors the state of objects in the array; S2: When the external thread locks, it creates a TraceLock class object, passes in the locked object and the lock number, and when the lock is successful, increases the object count of the corresponding number index in the internal cache array by one, and then the thread continues to execute, otherwise the thread is blocked and waiting; S3: When the external thread has finished using the lock, it will reduce the object count of the corresponding number index in the internal cache array by one, and clear the timer at the same time; S4: The monitoring thread inside TrackLock monitors the array regularly. When it finds that the count of an object is greater than 0 and the count exceeds a set time, it prints out the lock number that has not been released for a long time. S5: When a thread deadlock occurs, the user can use the printed log to determine which two lock numbers have not been unlocked for a long time. The two numbers can be used to locate the location where the synchronization lock is called, and the code can be corrected based on this. S6: Use the Visual Studio debugger to locate, including the following steps: S601: Reproduce the deadlock scenario, reproduce the deadlock problem, and trigger the program to enter the deadlock state through specific input and operation sequences; S602: Start debugging. In Visual Studio, run the program and wait for a deadlock to occur. When the program is stuck, enter the debugging mode. S603: Check the thread window, open the thread window in the debug menu, and observe the status of all running threads. In the deadlock state, the thread is in a waiting state; S604: Check the call stack. For threads in the waiting state, right-click the thread and select Switch to Frame, Display Call Stack. Based on this, check the method currently being executed by each thread and the location where the lock is acquired. If the thread is executing a method containing a lock statement and is always in the state of waiting for the lock to be released, it is determined to be the cause of the deadlock. S7: Use the analysis tool, including the following steps: S701: Install and configure tools, install ANTSPerformanceProfiler, and configure it to analyze C# programs; S702: Run the analysis, start ANTSPerformanceProfiler and reproduce the deadlock scenario. The tool will collect data in the background, including thread execution time and method call frequency; S703: Check the thread behavior and lock contention. In the report of the analysis tool, find the part about thread synchronization and lock. S8: Review the code and carefully check all places where the lock keyword is used in the code. When multiple lock statements are nested, observe the order in which they are acquired. If the acquisition order is different, it is considered a deadlock.

2. According to claim 1, a method for locating a program stuck due to C# synchronous lock deadlock, characterized in that: In S2, the number is used to locate the code position, and the number cannot be repeated.

3. According to claim 1, a method for locating a program stuck due to C# synchronous lock deadlock, characterized in that: In S5, the step of thread deadlock occurring includes the following operation steps: S501: Thread 1 creates a TrackLock, the lock object is obj1, and the number is 0. At this time, the lock object obj1 is idle, so the lock is successful, and the LockInfo with array index 0 increases the count by 1; S502: Thread 2 creates a TrackLock, the lock object is obj2, and the number is 5. At this time, the lock object obj2 is idle, so the lock is successful, and the LockInfo with array index 5 increases the count by 1; S503: Thread 1 creates another TrackLock, the lock object is obj2, and the number is 3, but obj2 has been locked by Thread 2, so Thread 1 is blocked at this time; S504: Process 2 creates another TrackLock, the lock object is obj1, the number is n, but obj1 has been locked by thread 1, so thread 2 is blocked at this time; S505: After executing the above correction, threads 1 and 2 are deadlocked with each other, causing the program to freeze.

4. According to claim 1, a method for locating a program stuck due to C# synchronous lock deadlock, characterized in that: In S1, the independent thread for monitoring the state of objects in the array includes the following steps: S101: The thread first traverses the LockInfo array and takes out the first object; S102: Check whether the count of the LockInfo object is greater than 0. If not, determine whether it is the last one in the array. S103: Check whether the recorded time in LockInfo is greater than 15 seconds. If not, increase the timer and determine whether it is the last one in the array. S104: If the LockInfo count is greater than 0 and the timer exceeds 15 seconds, it indicates that the lock is deadlocked, and the lock number in LockInfo is printed out; S105: After checking the current LockInfo, confirm whether it is the last one in the array. If not, directly obtain the array to check the next LockInfo; S106: If the array traversal is completed, wait for 3 seconds, then return to S101 and start traversing the array again.

Images