# Deadlocks Detection in Multithreaded Applications Based on Source Code Analysis
## 7 Using the Source Code Model of the Multithreaded Application in Practice  
### Leading Example  
A system where it is essential to locate the resource conflict causing the deadlock phenomenon can be an application in which users define tasks to be performed by the system based on date and time. Let this system be able to take non-standard actions if one of the predefined dates occurs. Figure 7 shows a block diagram of an algorithm describing the operation of such an application, and its input data provided by the user will be a sequence with the following structure, compatible with the cron program:  
1. minute,
2. hour,
3. day of the month,
4. month,
5. day of week,
6. user,
7. job.  
Testing such applications is very difficult and time-consuming. The sample application runs tasks with an accuracy of one minute. To test how such an application works, one needs to perform tests  
Figure 7: A simplified block diagram of a sample application algorithm.  
for each scheduled minute of the year, which, assuming it's a leap year, gives 527,040 combinations. After taking into account the days of the week, the number of combinations increases to 648,000. Depending on how complex the application code is, it may not be possible to test all possible combinations. Assuming that it will take 0.5 ms to perform one test, testing all possible combinations will take approximately 5 min and 24 s. Tools for detecting undesirable phenomena in multithreaded applications, including the CTrigger tool focused on the phenomenon of atomicity violation, are based on performing tests on a selected piece of code that potentially has a resource conflict causing this phenomenon [18; 21; 22]. As a result, these types of tools do the same work as load tests, but the former is more efficient. This is because the whole code is not tested, but only parts of it. Further in the article, it is assumed that the solution based on the source code model of a multithreaded application will be compared with a tool similar to CTrigger, however, focused on detecting resource conflicts causing deadlocks. For the sake of simplicity, let the proposed solution be called deadlock detector (DD).  
Figure 8 has an operation graph that corresponds to a fragment of the application described above; i.e., it runs a given number times two tasks. Let it be called AP1 (source code: [[http://bit.ly/2](http://bit.ly/2) ZBqhrO]([http://bit.ly/2](http://bit.ly/2) ZBqhrO)). If the task data meet the start condition, then the task is run. If the condition is not met, the application does not take any action. Running tasks is displaying data to the standard output of the application, which is a shared resource.  
The sample application has an error resulting from skipping the unlocking operation in one of the control instructions branches. In the figure showing the algorithm of operation, this error is located in the block \"Perform Other Task\". Therefore, let the application described above, whose operation graph is below, be an example to which the rest of the article will refer.  
\(T_{AP1}=(t_{0},t_{1},t_{2})\),  
\(U_{AP1}=(\{t_{0}\},\{t_{1},t_{2}\},\{t_{0}\})\),  
\(R_{AP1}=\{(std::cout),(std::cerr