A positioning method for program freezing caused by C# synchronization lock deadlock

Abstract

The application discloses a positioning method for program freezing caused by C# synchronization lock deadlock, and relates to the field of computer application, S1: defining a TraceLock for tracking the class object information of a lock; S2: creating a TraceLock class object when an external thread is locked, and adding one to the object count of the corresponding number index of the internal cache array; S3: when the external thread is released after use, reducing one from the object count of the corresponding number index of the internal cache array; S4: the monitoring thread in the TrackLock, which monitors the array at regular time intervals; S5: when thread deadlock occurs, the user can determine which two lock numbers have not been unlocked for a long time through printed logs, and the position of the calling synchronization lock can be located through the two numbers. The positioning method for program freezing caused by C# synchronization lock deadlock has the advantages that when thread synchronization is realized by using a synchronization lock, if deadlock occurs, the method can quickly locate the code position where the deadlock occurs through logs.

Description

Technical Field

[0001] This invention relates to the field of computer applications, and in particular to a method for locating program freezes caused by C# synchronization deadlock. Background Technology

[0002] As software becomes increasingly complex, multithreading is a common technique to improve execution efficiency. However, when multiple threads execute concurrently and access the same resource, dirty reads and false reads can easily occur. To prevent this, synchronization locks were developed. Each thread locks the resource before accessing it. If a thread successfully locks the resource, it gains the right to read and write it, while other threads cannot lock it. Only after the thread finishes reading and writing and releases the lock can other threads successfully lock it.

[0003] While synchronization locks solve the problems of dirty reads and misreads of the same resource, they also introduce new potential problems, such as deadlock. For example, if there are two shared resources, two synchronization locks are needed. For instance, if there are two threads T1 and T2, two shared resources S1 and S2, and two synchronization locks L1 and L2, and thread T1 locks S1 with L1 while thread T2 locks S2 with L2, and then T1 wants to access S2, but S2 is already locked by T2, it can only wait. Similarly, T2 wants to use S1, but S1 is already locked by T1, so it can only wait as well. Thus, T1 and T2 are both waiting for the other to release the resource lock they need, causing the program to freeze.

[0004] Deadlock is not an inevitable problem and is relatively insidious, making it difficult to locate once it occurs, especially when the program has many threads and uses a large number of synchronization locks, which makes troubleshooting even more difficult.

[0005] Therefore, it is necessary to propose a method for locating program freezes caused by C# synchronization deadlocks to solve the above problems. Summary of the Invention

[0006] The main objective of this invention is to provide a method for locating program freezes caused by C# synchronization deadlocks, which can effectively solve the problems in the background art.

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

[0008] A method for locating program freezes caused by C# synchronization deadlocks, including the following steps:

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

[0010] S2: When an external thread acquires a lock, it creates a TraceLock object, passing in the object to be locked and the lock number. If the lock is successfully acquired, the count of the object at the corresponding index in the internal cache array is incremented by one, and then the thread continues to execute; otherwise, the thread is blocked and waits.

[0011] S3: When an external thread finishes using the lock and releases it, it decrements the count of the object at the corresponding index in the internal cache array by one and resets the timer to zero.

[0012] S4: The monitoring thread inside TrackLock periodically monitors this array. When it finds that the count of a certain object is greater than 0 and the timer 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 determine which two lock numbers have not been unlocked for a long time by checking the printed logs. These two numbers can be used to locate the location where the synchronization lock was called, and the code can be corrected accordingly.

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

[0015] S601: Reproduce deadlock scenarios and problems by triggering the program into a 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 freezes, enter debug mode.

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

[0018] S604: View the call stack. For threads in a waiting state, right-click the thread and select Switch to Frame, Show Call Stack. Based on this, you can see the method that each thread is currently executing and the position where it acquired the lock. If a thread is executing a method containing a lock statement and is in a state of waiting for the lock to be released, it is determined to be the cause of deadlock.

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

[0020] S701: Installation and configuration tools, install ANTSPerformanceProfiler and configure it for analysis of 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: Examine thread behavior and lock contention. In the analysis tool's report, look for sections on thread synchronization and locks.

[0023] S8: Code review. Carefully examine all places in the code that use the `lock` keyword. 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 step S2, the number is used to locate the code position, and the number cannot be repeated.

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

[0026] S501: Thread 1 creates a TrackLock with lock object obj1 and number 0. At this time, lock object obj1 is free, so the lock is successfully acquired. The LockInfo at array index 0 increments the count by 1.

[0027] S502: Thread 2 creates a TrackLock with lock object obj2 and number 5. At this time, lock object obj2 is free, so the lock is successfully acquired. The LockInfo array with index 5 increments the count by 1.

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

[0029] S504: Thread 2 creates another TrackLock, the lock object is obj1, and the number is n. However, obj1 has already been locked by thread 1, so thread 2 is blocked at this time.

[0030] S505: After the above correction is performed, threads 1 and 2 deadlock each other, causing the program to freeze.

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

[0032] S101: The thread first iterates through the LockInfo array and retrieves the first object from it;

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

[0034] S103: Check if the time recorded in LockInfo is greater than 15 seconds. If it is not greater than 15 seconds, increment the timer and then check if it is the last element in the array.

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

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

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

[0038] Compared with existing technologies, this invention provides a method for locating program freezes caused by C# synchronization deadlocks, which has the following beneficial effects:

[0039] This method, based on C# synchronization lock deadlock, can help locate the code causing the deadlock when a deadlock occurs while the program uses synchronization locks to achieve thread synchronization. It can quickly pinpoint the code location where the deadlock occurred by checking the logs. Attached Figure Description

[0040] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0041] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0042] like Figure 1 As shown, a method for locating program freezes caused by C# synchronization deadlocks includes the following steps:

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

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

[0045] S101: The thread first iterates through the LockInfo array and retrieves the first object from it;

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

[0047] S103: Check if the time recorded in LockInfo is greater than 15 seconds. If it is not greater than 15 seconds, increment the timer and then check if it is the last element in the array.

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

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

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

[0051] S2: When an external thread acquires a lock, it creates a TraceLock object, passing in the object to be locked and the lock number. The number is used to locate the code position and cannot be repeated. When the lock is successfully acquired, the count of the object at the corresponding index in the internal cache array is incremented by one, and then the thread continues to execute; otherwise, the thread is blocked and waits.

[0052] S3: When an external thread finishes using the lock and releases it, it decrements the count of the object at the corresponding index in the internal cache array by one and resets the timer to zero.

[0053] S4: The monitoring thread inside TrackLock periodically monitors this array. When it finds that the count of a certain object is greater than 0 and the timer 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 determine which two lock numbers have not been unlocked for a long time by checking the printed logs. These two numbers can be used to locate the location where the synchronization lock was called, and the code can be corrected accordingly.

[0055] The steps involved in a thread deadlock include the following:

[0056] S501: Thread 1 creates a TrackLock with lock object obj1 and number 0. At this time, lock object obj1 is free, so the lock is successfully acquired. The LockInfo at array index 0 increments the count by 1.

[0057] S502: Thread 2 creates a TrackLock with lock object obj2 and number 5. At this time, lock object obj2 is free, so the lock is successfully acquired. The LockInfo array with index 5 increments the count by 1.

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

[0059] S504: Thread 2 creates another TrackLock, the lock object is obj1, and the number is n. However, obj1 has already been locked by thread 1, so thread 2 is blocked at this time.

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

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

[0062] S601: Reproduce deadlock scenarios and problems by triggering the program into a 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 freezes, enter debug mode.

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

[0065] S604: View the call stack. For threads in a waiting state, right-click the thread and select Switch to Frame, Show Call Stack. Based on this, you can see the method that each thread is currently executing and the position where it acquired the lock. If a thread is executing a method containing a lock statement and is in a state of waiting for the lock to be released, it is determined to be the cause of deadlock.

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

[0067] S701: Installation and configuration tools, install ANTSPerformanceProfiler and configure it for analysis of 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: Examine thread behavior and lock contention. In the analysis tool's report, look for sections on thread synchronization and locks.

[0070] S8: Code review. Carefully examine all places in the code that use the `lock` keyword. 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 encoding implementation method:

[0072]

[0073]

[0074]

[0075]

[0076] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for locating program freezes caused by C# synchronization deadlocks, characterized in that: The following steps are included: S1: Define a TraceLock to trace information about lock class objects. Internally, it contains a static array of lock information and an independent thread that monitors the state of the objects in the array. S2: When an external thread acquires a lock, it creates a TraceLock object, passing in the object to be locked and the lock number. If the lock is successfully acquired, the count of the object at the corresponding index in the internal cache array is incremented by one, and then the thread continues to execute; otherwise, the thread is blocked and waits. S3: When an external thread finishes using the lock and releases it, it decrements the count of the object at the corresponding index in the internal cache array by one and resets the timer to zero. S4: The monitoring thread inside TrackLock periodically monitors this array. When it finds that the count of a certain object is greater than 0 and the timer 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 determine which two lock numbers have not been unlocked for a long time by checking the printed logs. These two numbers can be used to locate the location where the synchronization lock was called, and the code can be corrected accordingly. S6: Use the Visual Studio debugger to locate the problem, including the following steps: S601: Reproduce deadlock scenarios and problems by triggering the program into a deadlock state through a specific sequence of inputs and operations. S602: Start debugging. In Visual Studio, run the program and wait for a deadlock to occur. When the program freezes, enter debug mode. S603: View the thread window. Open the thread window in the debug menu and observe the status of all running threads. In a deadlock state, the thread is in a waiting state. S604: View the call stack. For threads in a waiting state, right-click the thread and select Switch to Frame, Show Call Stack. Based on this, you can see the method that each thread is currently executing and the position where it acquired the lock. If a thread is executing a method containing a lock statement and is in a state of waiting for the lock to be released, it is determined to be the cause of deadlock. S7: Use the analysis tools, including the following steps: S701: Installation and configuration tools, install ANTSPerformanceProfiler and configure it for analysis of 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: Examine thread behavior and lock contention. In the analysis tool's report, look for sections on thread synchronization and locks. S8: Code review. Carefully examine all places in the code that use the `lock` keyword. 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. The method for locating program freezes caused by C# synchronization lock deadlock as described in claim 1, characterized in that: In S2, the number is used to locate the code position, and the number cannot be repeated.

3. The method for locating program freezes caused by C# synchronization lock deadlock as described in claim 1, characterized in that: In S5, the steps that cause a thread deadlock include the following operations: S501: Thread 1 creates a TrackLock with lock object obj1 and number 0. At this time, lock object obj1 is free, so the lock is successfully acquired. The LockInfo at array index 0 increments the count by 1. S502: Thread 2 creates a TrackLock with lock object obj2 and number 5. At this time, lock object obj2 is free, so the lock is successfully acquired. The LockInfo array with index 5 increments the count by 1. S503: Thread 1 creates another TrackLock, the lock object is obj2, the number is 3, but obj2 has already been locked by thread 2, so thread 1 is blocked at this time; S504: Thread 2 creates another TrackLock with the lock object obj1 and the lock number n. However, obj1 has already been locked by thread 1, so thread 2 is blocked at this time. S505: After executing the above steps, threads 1 and 2 deadlock each other, causing the program to freeze.

4. The method for locating program freezes caused by C# synchronization lock deadlock as described in claim 1, characterized in that: In step S1, the independent thread monitoring the state of objects within the array includes the following steps: S101: The thread first iterates through the LockInfo array and retrieves the first object from it; S102: Check if the count of the LockInfo object is greater than 0. If it is not greater than 0, determine if it is the last one in the array. S103: Check if the time recorded in LockInfo is greater than 15 seconds. If it is not greater than 15 seconds, increment the timer and then check if it is the last element in the array. S104: If the LockInfo count is greater than 0 and the count exceeds 15 seconds, it indicates that the lock is deadlocked. Print out the lock number in LockInfo. S105: After checking the current LockInfo, confirm whether it is the last one in the array. If not, directly obtain the array and check the next LockInfo. S106: If the array traversal is complete, wait 3 seconds, then return to S101 and start traversing the array again.

Images