A non-intrusive c program deadlock location method

Abstract

This invention provides a non-intrusive method for locating deadlocks in C programs, comprising the following steps: S1: Modify the Pthreads library used by the C program in the Linux operating system, add a new synchronization and mutual exclusion function, and compile to generate a new Pthreads library; S2: Modify the system header files related to the original synchronization and mutual exclusion function in the Linux operating system, and use macro definitions to make the original synchronization and mutual exclusion function point to the new synchronization and mutual exclusion function; S3: The user uses the original synchronization and mutual exclusion function and the new Pthreads library to jointly write, compile, and run a multi-threaded C program; S4: The deadlock detection program obtains the running data of the multi-threaded C program from the computer's shared memory. If a deadlock occurs in one or more threads, running the deadlock detection program can locate the specific source code file name and line of code of the deadlocked thread. The deadlock location method proposed in this invention can accurately locate the source code file name and line of code in the C program where a deadlock occurs without inserting other code into the user's C code, thus improving the efficiency of users in finding deadlocked programs.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a non-intrusive method for deadlocking C programs in the Linux operating system. Background Technology

[0002] The International Organization for Standardization (IEEE) has defined a set of Application Programming Interface (API) standards for software running on various UNIX operating systems. These standards are collectively known as the Portable Operating System Interface of UNIX (POSIX). Within the POSIX standard, there is a dedicated API standard for multithreading: Pthreads (POSIX threads). In current Linux operating systems, C is a widely used programming language, and it provides a multithreading library that conforms to the Pthreads standard.

[0003] When developing C programs using the Pthreads multithreading library on the Linux operating system, deadlocks may occur when multiple threads are running if the program design is flawed. Once a deadlock occurs, its detection becomes crucial. Currently, various deadlock detection algorithms exist, with different implementations for different research areas. However, in practical applications, the following technical problems inevitably arise:

[0004] (1) Intrusive deadlock detection algorithms can affect user program code.

[0005] Intrusive methods refer to modifying the user-written program source code to detect deadlocks. This involves inserting new code into the source code to obtain necessary detection data, or writing the required detection data to a file, which is then analyzed by the deadlock detection algorithm to identify deadlocks. This newly added redundant code is called instrumentation code. This approach results in a mixture of source code and instrumentation code, making it difficult for users to distinguish between the two and increasing the difficulty of code management.

[0006] (2) Non-intrusive deadlock detection algorithms have difficulty accurately locating the filenames and lines of code that cause deadlocks.

[0007] Non-intrusive deadlock detection refers to the ability to detect multi-threaded deadlocks in a user's program without modifying the program's source code. Non-intrusive deadlock detection algorithms are extremely rare in Linux operating systems; currently, one such algorithm is Valgrind. While Valgrind doesn't instrument the source code itself, it does instrument the executable code generated from the compiled source code. During program execution, this instrumented code outputs necessary detection data or writes the data to a file for later analysis. Because this method adds new code to the executable, the lines of code in the source code and the executable code do not correspond one-to-one, making it difficult to accurately pinpoint the line of code where the deadlock occurred.

[0008] Chinese invention patent "A testing system and method for deadlock defects in distributed system programs" (application number 201810799683X) provides a testing system and method for deadlock defects in distributed system programs. By simulating network events in a distributed system and combining them with lock events executed by the software of the distributed system under test on a single machine, a priority-based thread scheduling module is used to convert the parallel logic of threads into serial logic, and a deadlock detection module is used to determine deadlock. This achieves probabilistically guaranteed detection of deadlock defects in distributed systems on a single machine. However, this invention does not provide precise deadlock location.

[0009] Chinese invention patent "Memory Optimization Method Based on Thread Deadlock, Mobile Terminal, and Readable Storage Medium" (application number 2017112452130) discloses a memory optimization method based on thread deadlock, a mobile terminal, and a readable storage medium. The method records the screen-off standby time of the mobile terminal during each preset usage period to establish a screen-off standby time table, stores this table in a preset storage area, and then periodically monitors whether preset threads are in a deadlock state. This invention does not address the deadlock positioning problem in the user program source code.

[0010] Chinese invention patent “System and Method Including Deadlock Detector” (application number 2017109852320) provides a deadlock detection system based on hardware blocks, a deadlock detector and interconnection devices, but is not used for deadlock detection of user program source code.

[0011] Chinese invention patent "Thread Detection Method, Terminal, and Computer-Readable Storage Medium" (application number 2017104217887) provides a thread detection method comprising the following steps: when a task thread calls a core module, locking the core module using a preset public lock; starting a detection thread and periodically attempting to acquire the preset public lock to determine if the core module is available; if the preset public lock cannot be acquired within a preset timeout period, the core module is determined to be unavailable, and a deadlock is determined to have occurred between the task thread and the core module. This invention is used to detect deadlocks in system services but does not address deadlock positioning issues in user program source code.

[0012] For C programs written based on Pthreads in the Linux operating system, if multiple threads of the program deadlock during execution, it is very necessary and of great significance to design a non-intrusive deadlock detection algorithm that can not only detect the cause of the deadlock in a timely manner, but also accurately locate the source code file name and line of code where the deadlock occurred without modifying the C program source code (hereinafter referred to as "C code"). Summary of the Invention

[0013] This invention addresses the problems existing in the prior art by providing a non-intrusive method for locating deadlocks in C programs. For C programs written using Pthreads on Linux operating systems, if multiple threads of the program deadlock during execution, the source code file and line of code at the time of the deadlock can be accurately located without modifying the source code. This effectively solves the problem of accurately finding the source code file name and line of code in a C program where a deadlock occurs, greatly facilitating user work. Users can promptly modify the problematic source code file and line of code provided by this method, effectively preventing program deadlocks.

[0014] The above-mentioned technical objective of the present invention is achieved through the following technical solution:

[0015] A non-intrusive method for deadlocking C programs includes the following steps:

[0016] S1: Modify the Pthreads library used by the C program in the Linux operating system, add new synchronization and mutual exclusion functions, and compile to generate a new Pthreads library;

[0017] S2: Modify the system header files related to the original synchronization and mutual exclusion function in the Linux operating system, and use macro definitions to point the original synchronization and mutual exclusion function to the new synchronization and mutual exclusion function.

[0018] S3: Users can use the original synchronization and mutual exclusion functions and the new Pthreads library to write, compile and run multithreaded C programs.

[0019] S4: The deadlock detection program obtains the running data of the multi-threaded C program from the computer's shared memory. If a deadlock occurs in one or more threads, running the deadlock detection program can locate the specific source code file name and line of code of the deadlocked thread.

[0020] Furthermore, the specific steps of S1 include:

[0021] S11: Download the source code of the Pthreads library used by the C program from the website of the Linux operating system;

[0022] S12: In the source code of the Pthreads library in S11, find the implementation files of the original synchronization mutex functions related to critical sections, read-write locks and semaphores in turn;

[0023] S13: Design a new synchronization and mutual exclusion function in the implementation file of S12 respectively;

[0024] S14: Recompile and generate a new Pthreads library based on each new synchronization and mutual exclusion function in S13;

[0025] S15: Replace the original Pthreads library in the Linux operating system with the new Pthreads library from S14.

[0026] Furthermore, the specific steps of S13 include:

[0027] S131: In the implementation file, each original synchronization and mutual exclusion function in S12 is copied again and placed after the original synchronization and mutual exclusion function. The newly copied original synchronization and mutual exclusion function is renamed to form a new synchronization and mutual exclusion function.

[0028] S132: Add two parameters to each new synchronization mutex function in S131, namely the file name and the line of code;

[0029] S133: Add entry code to each new synchronization mutex function that occupies the critical section, the read-write lock, and the semaphore, and write the status, file name, line of code, and other information of the current thread waiting for the critical section, the read-write lock, and the semaphore into the shared memory;

[0030] S134: Add exit code to each new synchronization mutex function that occupies the critical section, the read-write lock, and the semaphore, changing the state of the current thread waiting for the critical section, the read-write lock, and the semaphore in shared memory to the used state;

[0031] S135: Add exit code to each new synchronization mutex function that exits the critical section, the read-write lock, and the semaphore, and delete the update information in the shared memory of this thread in S134.

[0032] Furthermore, the specific steps of S2 include:

[0033] S21: Locate the system header file related to the original synchronization mutex function on the Linux operating system;

[0034] S22: Use the C language preprocessing directive #define macro definition to redirect the original synchronization mutex function in S21 to the new synchronization mutex function in S13;

[0035] S23: Call the original synchronization and mutual exclusion function, and pass the source code file name and line of code of the original synchronization and mutual exclusion function defined by the #define macro as parameters to the new synchronization and mutual exclusion function in S22.

[0036] Furthermore, the specific steps of S3 include:

[0037] S31: Users use the original synchronization mutex function to write multithreaded C code;

[0038] S32: Use the new Pthreads library to compile the C code of S31 into an executable program;

[0039] S33: Run the executable program.

[0040] Furthermore, the specific steps of S4 include:

[0041] S41: Design a deadlock detection program;

[0042] S42: The deadlock detection program obtains the running data of the multi-threaded C program in S33 from the shared memory;

[0043] S43: Analyze the running data to determine whether the running multi-threaded C program has deadlocked;

[0044] S44: If a deadlock occurs in one or more threads, output deadlock data including the source code file name and line of code of the deadlocked thread.

[0045] Furthermore, the specific steps of S43 include:

[0046] S431: Based on the data written to the shared memory according to the entry code of S133, find all threads in the waiting state;

[0047] S432: Based on the data written to the shared memory according to the exit code of S134, find all threads that are in an occupied state;

[0048] S433: If one or more threads are in a circular waiting state, a deadlock occurs.

[0049] Furthermore, the critical section includes two commonly used synchronization and mutual exclusion functions, pthread_mutex_lock and pthread_mutex_unlock, which respectively represent requesting entry into the critical section and releasing the critical section.

[0050] Furthermore, the read-write lock includes three commonly used synchronization and mutual exclusion functions: pthread_rwlock_rdlock, pthread_rwlock_wrlock, and pthread_rwlock_unlock, which represent read lock, write lock, and release lock, respectively.

[0051] Furthermore, the semaphore includes two commonly used synchronization and mutual exclusion functions, sem_wait and sem_post, which represent waiting for the semaphore and releasing the semaphore, respectively.

[0052] Compared with existing technologies, this technical solution has the following advantages and beneficial effects:

[0053] When a multithreaded C program written using the Pthreads library in a Linux operating system encounters a deadlock during runtime, this method can accurately locate the source code file name and line of code in the C program where the deadlock occurred. This deadlock location method is non-intrusive, requiring no additional code to be inserted into the user's C code and having no impact on the user's program code; it greatly improves the efficiency of users in finding program deadlocks. Attached Figure Description

[0054] Figure 1 This is a flowchart of a non-intrusive C program deadlock positioning method according to an embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram of a deadlock procedure according to an embodiment of the present invention. Detailed Implementation

[0056] The present invention will be further described below with reference to embodiments and accompanying drawings:

[0057] Current computer CPUs typically employ multi-core design technology, where each core can independently execute computer instructions; multiple cores can process multiple computer instructions in parallel. With the development of parallelization in computer hardware technology, represented by CPUs, multithreaded software programming techniques have also become increasingly sophisticated and mature. A program can be divided into multiple threads during runtime, and these threads can run simultaneously on multiple CPU cores, thereby effectively improving program efficiency.

[0058] However, when a program runs in parallel using multiple threads, synchronization and mutual exclusion become two major challenges. Synchronization means that one thread must wait for the result of another thread's execution before it can continue. Mutual exclusion means that in addition to defining their own local variables, each thread in a program can also define global variables shared by all threads; typically, multiple threads are allowed to read a global variable simultaneously, but only one thread is allowed to write to a global variable at any given time. Otherwise, the variable's value becomes unpredictable, which can easily lead to program crashes.

[0059] Synchronization and mutual exclusion can lead to deadlocks among multiple threads in a flawed program. For example, when thread A is using global variable 'a', it also needs to use global variable 'b' which is being used by thread B; while thread B is using global variable 'b', it also needs to use global variable 'a' which is being used by thread A. In this case, the two threads will deadlock because they are waiting for each other's results. Deadlock can also occur when three or more threads are waiting for the results of other threads, forming a waiting cycle.

[0060] The Pthreads multithreading library in C provides three commonly used methods to support synchronization and mutual exclusion between threads: critical sections (Mutex), read-write locks (Lock), and semaphores (Semaphores). The corresponding functions are called synchronization and mutual exclusion functions.

[0061] (1) Critical region Mutex

[0062] A critical section (Mutex) includes two commonly used synchronization and mutual exclusion functions: `pthread_mutex_lock` and `pthread_mutex_unlock`, which respectively indicate requesting entry into the critical section and releasing the critical section. Only one thread can enter the critical section at any given time. The process entering the critical section can read and write global variables, and releases the critical section after the global variables have been read and written.

[0063] (2) Read-write lock

[0064] Read-write locks (Locks) include three commonly used synchronization and mutex functions: `pthread_rwlock_rdlock`, `pthread_rwlock_wrlock`, and `pthread_rwlock_unlock`, representing read lock, write lock, and lock release, respectively. When a thread prepares to read a global variable, it must first call the `pthread_rwlock_rdlock` function to acquire a read lock on that global variable; when a thread prepares to write to a global variable, it must first call the `pthread_rwlock_wrlock` function to acquire a write lock on that global variable. If a global variable already has a read lock, subsequent write locks must wait, but other read locks are allowed to access the global variable; conversely, if a global variable already has a write lock, subsequent read and write locks must wait until the write lock is released.

[0065] (3) Semaphore

[0066] A semaphore includes two commonly used synchronization and mutex functions: `sem_wait` and `sem_post`, which represent waiting for and releasing a semaphore, respectively. Semaphores are typically represented by integers. When the value is greater than 0, the `sem_wait` request succeeds, the semaphore value is decremented by 1, and the thread continues running. When the value is less than or equal to 0, the thread is in a waiting state. When a thread calls `sem_post` to release the semaphore, the semaphore value is incremented by 1.

[0067] The following section further introduces a non-intrusive method for fixing deadlocks in C programs, such as... Figure 1 As shown, it includes the following steps:

[0068] S1: Modify the Pthreads library used by C programs in the Linux operating system, add new synchronization and mutex functions, and compile to generate a new Pthreads library. When the C program calls these new synchronization and mutex functions, the filename and line of code for each new synchronization and mutex function are written to the computer's shared memory.

[0069] S2: In the Linux operating system, modify the system header files related to the original synchronization and mutual exclusion function, and use macro definitions to make the original synchronization and mutual exclusion function point to the new synchronization and mutual exclusion function.

[0070] S3: Users can use the original synchronization and mutual exclusion functions and the new Pthreads library to write, compile and run multithreaded C programs.

[0071] S4: The deadlock detection program obtains the running data of the multi-threaded C program from the computer's shared memory. If a deadlock occurs in one or more threads, running the deadlock detection program can locate the specific source code file name and line of code of the deadlocked thread.

[0072] Furthermore, the specific steps of S1 include:

[0073] S11: Download the source code of the Pthreads library used by C programs from the Linux operating system website.

[0074] S12: In the source code of the Pthreads library in S11, find the implementation files of the original synchronization and mutex functions related to critical sections, read-write locks, and semaphores in sequence. These implementation files are the aforementioned synchronization and mutex functions pthread_mutex_lock, pthread_mutex_unlock, pthread_rwlock_rdlock, pthread_rwlock_wrlock, pthread_rwlock_unlock, sem_wait, and sem_post. The corresponding implementation files for these synchronization and mutex functions are pthread_mutex_lock.c, pthread_mutex_unlock.c, pthread_rwlock_rdlock.c, pthread_rwlock_wrlock.c, pthread_rwlock_unlock.c, sem_wait.c, and sem_post.c.

[0075] S13: Design a new synchronization and mutual exclusion function in the implementation file of S12.

[0076] S14: Recompile and generate a new Pthreads library based on each new synchronization and mutual exclusion function in S13.

[0077] S15: Replace the original Pthreads library in the Linux operating system with the new Pthreads library from S14.

[0078] Furthermore, the specific steps in S13 include:

[0079] S131: In the implementation file, each original synchronization mutex function from S12 is copied and placed after the original synchronization mutex function. The newly copied original synchronization mutex functions are renamed to form new synchronization mutex functions. In this embodiment, the name of the new synchronization mutex function can be prefixed with "new_" before the name of the original synchronization mutex function to form a new synchronization mutex function, such as: new_pthread_mutex_lock, new_pthread_mutex_unlock, new_pthread_rwlock_rdlock, new_pthread_rwlock_wrlock, new_pthread_rwlock_unlock, new_sem_wait, and new_sem_post.

[0080] S132: Add two parameters to each new synchronization mutex function in S131: the filename and the line of code.

[0081] S133: Add entry code to each new synchronization mutex function that occupies a critical section, read-write lock, and semaphore. Write the state, filename, and line of code of the thread waiting for the critical section, read-write lock, and semaphore to shared memory. Specifically, the entry code writes "thread id:resource category:resource addr:filename:line of code:wait" to shared memory. "Thread id" represents the thread calling the function; "resource category" represents one of four strings: "mutex", "readlock", "writelock", and "semaphore", representing a critical section, read lock, write lock, and semaphore, respectively; "resource addr" represents the address of the variable for the critical section, read-write lock, and semaphore in a program, used to distinguish each resource; for simplicity, it is represented by "1", "2", and "3" in the following examples; "filename" represents the filename of the user's source code that calls the synchronization mutex function; "line of code" represents the line number in the user's source code file that calls the function; and "wait" indicates that the thread is in a waiting state. These functions include new_pthread_mutex_lock, new_pthread_rwlock_rdlock, new_pthread_rwlock_wrlock, new_sem_wait, etc.

[0082] S134: Add exit code to each new synchronization mutex function that occupies a critical section, read-write lock, and semaphore. This changes the current thread's state of waiting for the critical section, read-write lock, or semaphore in shared memory to a "using" state. Specifically, the exit code writes "thread id:resource type:resource addr:filename:line of code:use" to shared memory. Here, "use" indicates that the thread is in an occupied state. These synchronization mutex functions include new_pthread_mutex_lock, new_pthread_rwlock_rdlock, new_pthread_rwlock_wrlock, and new_sem_wait.

[0083] S135: Add exit code to each new synchronization mutex function that exits critical sections, read-write locks, and semaphores. This exit code removes the updated information of the current thread in the shared memory from S134. Specifically, it removes the sequence "thread id:resource type:resource addr:filename:line of code:use" from the shared memory. These synchronization mutex functions include new_pthread_mutex_unlock, new_pthread_rwlock_unlock, and new_sem_post.

[0084] Furthermore, the specific steps of S2 include:

[0085] S21: Locate the system header files related to the original synchronization and mutex functions on the Linux operating system. In Linux, these are typically the two system header files: / usr / include / pthread.h and / usr / include / semaphore.h.

[0086] S22: Use the C language preprocessor directive #define macro definition to redirect the original synchronization mutex function in S21 to the new synchronization mutex function in S13. The #define macro definition is a preprocessor directive in the C language.

[0087] S23: Calls the original mutex function, passing the source code filename and line number of the original mutex function (defined via the #define macro) as parameters to the new mutex function in S22. For example, "#define pthread_mutex_lock(x)new_pthread_mutex_lock(x, __FILE__, __LINE__)". When the user calls the pthread_mutex_lock mutex function in the C program, it actually calls the new_pthread_mutex_lock mutex function. Besides the parameter x being passed from the original mutex function to the new one, the source code filename and line number of the original mutex function can be obtained from the __FILE__ and __LINE__ macros and assigned to the new mutex function.

[0088] Furthermore, the specific steps of S3 include:

[0089] S31: Users use the original synchronization and mutex functions to write multithreaded C code.

[0090] S32: Use the new Pthreads library to compile the C code of S31 into an executable program.

[0091] S33: Run the executable program.

[0092] Furthermore, the specific steps of S4 include:

[0093] S41: Design a deadlock detection program.

[0094] S42: The deadlock detection program obtains the running data of the multi-threaded C program in S33 from the shared memory.

[0095] S43: Analyze the above running data to determine whether the running multi-threaded C program has deadlocked.

[0096] S44: If a deadlock occurs in one or more threads, output deadlock data including the source code file name and line of code of the deadlocked thread.

[0097] Furthermore, the specific steps of S43 include:

[0098] S431: Based on the data written to the shared memory by the entry code of S133, find all threads in the waiting state, that is, find all threads in the waiting state according to "thread id:resource category:resource addr:filename:line of code:wait".

[0099] S432: Based on the data written to the shared memory according to the exit code of S134, find all threads in the occupied state, that is, find all threads in the occupied state according to "thread id:resource category:resource addr:file name:code line:use".

[0100] S433: If one or more threads are in a circular waiting state, a deadlock occurs.

[0101] This application does not emphasize a specific deadlock detection algorithm; any algorithm that uses data stored in shared memory for deadlock detection is acceptable.

[0102] In this embodiment, there is a deadlock state such as Figure 2 As shown, a deadlock is formed by six data points: Thread Thread1 already holds critical section "mutex:1" and is waiting for critical section "mutex:2"; Thread Thread2 already holds critical section "mutex:2" and is waiting for critical section "mutex:3"; Thread Thread3 already holds critical section "mutex:3" and is waiting for critical section "mutex:1". These six data points show that all three threads hold one critical section and each wants to acquire a critical section already held by another thread. This prevents all three threads from obtaining the desired critical section, resulting in a deadlock.

[0103] "Thread1:mutex:1:ac:10:use"

[0104] "Thread1:mutex:2:bc:20:wait"

[0105] "Thread2:mutex:2:bc:25:use"

[0106] "Thread2:mutex:3:cc:30:wait"

[0107] "Thread3:mutex:3:cc:35:use"

[0108] "Thread3:mutex:1:ac:15:wait"

[0109] From the above 6 data points, it can be clearly located that the file names of the critical sections when the deadlock occurred are ac, bc, bc, cc, cc, ac, and their corresponding code lines are 10, 20, 25, 30, 35, and 15, respectively.

[0110] This technical solution has the following advantages and beneficial effects:

[0111] When a multithreaded C program written using the Pthreads library in a Linux operating system encounters a deadlock during runtime, this method can accurately locate the source code file name and line of code in the C program where the deadlock occurred. This deadlock location method is non-intrusive, requiring no additional code to be inserted into the user's C code and having no impact on the user's program code; it greatly improves the efficiency of users in finding program deadlocks.

[0112] The foregoing has provided a detailed description of a non-intrusive C program deadlock positioning method provided by embodiments of the present invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention; furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0113] Certain terms are used in the specification and claims to refer to specific components. Those skilled in the art will understand that different organizations may use different terms to refer to the same component. This specification and claims do not distinguish components based on differences in name, but rather on differences in function. The term "comprising" as used throughout the specification and claims is an open-ended term and should be interpreted as "comprising but not limited to." The following descriptions of preferred embodiments of the invention are intended to illustrate the general principles of the invention and are not intended to limit the scope of the invention. The scope of protection of this invention is determined by the appended claims.

[0114] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0115] The foregoing description illustrates and describes several preferred embodiments of the present invention. However, as previously stated, it should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the inventive concept described herein through the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A non-invasive C program deadlock location method, characterized by, Includes the following steps: S1: Modify the Pthreads library used by the C program in the Linux operating system, add new synchronization and mutual exclusion functions, and compile to generate a new Pthreads library; S11: Download the source code of the Pthreads library used by the C program from the website of the Linux operating system; S12: In the source code of the Pthreads library in S11, find the implementation files of the original synchronization mutex functions related to critical sections, read-write locks and semaphores in turn; S13: Design a new synchronization and mutual exclusion function in the implementation file of S12 respectively; S131: In the implementation file, each original synchronization and mutual exclusion function in S12 is copied again and placed after the original synchronization and mutual exclusion function. The newly copied original synchronization and mutual exclusion function is renamed to form a new synchronization and mutual exclusion function. S132: Add two parameters to each new synchronization mutex function in S131, namely the file name and the line of code; S133: Add entry code to each new synchronization mutex function that occupies the critical section, the read-write lock, and the semaphore, and write the status, file name, line of code, and other information of the current thread waiting for the critical section, the read-write lock, and the semaphore into the shared memory; S134: Add exit code to each new synchronization mutex function that occupies the critical section, the read-write lock, and the semaphore, changing the state of the current thread waiting for the critical section, the read-write lock, and the semaphore in shared memory to the used state; S135: Add exit code to each new synchronization mutex function that exits the critical section, the read-write lock, and the semaphore, and delete the update information in the shared memory of this thread in S134; S14: Recompile and generate a new Pthreads library based on each new synchronization and mutual exclusion function in S13; S15: Replace the original Pthreads library in the Linux operating system with the new Pthreads library from S14; S2: Modify the system header files related to the original synchronization and mutual exclusion function in the Linux operating system, and use macro definitions to point the original synchronization and mutual exclusion function to the new synchronization and mutual exclusion function. S21: Locate the system header file related to the original synchronization mutex function on the Linux operating system; S22: Use the C language preprocessing directive #define macro definition to redirect the original synchronization mutex function in S21 to the new synchronization mutex function in S13; S23: Call the original synchronization mutex function, and pass the source code file name and line of code of the original synchronization mutex function defined by the #define macro as parameters to the new synchronization mutex function in S22; S3: Users can use the original synchronization and mutual exclusion functions and the new Pthreads library to write, compile and run multithreaded C programs. S31: Users use the original synchronization mutex function to write multithreaded C code; S32: Use the new Pthreads library to compile the C code of S31 into an executable program; S33: Run the executable program; S4: The deadlock detection program obtains the running data of the above multi-threaded C program from the computer's shared memory. If a deadlock occurs in one or more threads, running the deadlock detection program can locate the specific source code file name and line of code of the deadlocked thread. S41: Design a deadlock detection program; S42: The deadlock detection program obtains the running data of the multi-threaded C program in S33 from the shared memory; S43: Analyze the running data to determine whether the running multi-threaded C program has deadlocked; S431: Based on the data written to the shared memory according to the entry code of S133, find all threads in the waiting state; S432: Based on the data written to the shared memory according to the exit code of S134, find all threads that are in an occupied state; S433: If one or more threads are in a circular waiting state, a deadlock occurs. S44: If a deadlock occurs in one or more threads, output deadlock data including the source code file name and line of code of the deadlocked thread.

2. The non-invasive C program deadlock locating method of claim 1, wherein, The critical section includes two commonly used synchronization and mutual exclusion functions, pthread_mutex_lock and pthread_mutex_unlock, which respectively represent requesting entry into the critical section and releasing the critical section.

3. The non-intrusive C program deadlock positioning method according to claim 2, characterized in that, The read-write lock includes three commonly used synchronization and mutual exclusion functions: pthread_rwlock_rdlock, pthread_rwlock_wrlock, and pthread_rwlock_unlock, which represent read lock, write lock, and release lock, respectively.

4. The non-intrusive C program deadlock positioning method according to claim 1, characterized in that, The semaphores include two commonly used synchronization and mutual exclusion functions: sem_wait and sem_post, which represent waiting for the semaphore and releasing the semaphore, respectively.

Images