# Deadlocks Detection in Multithreaded Applications Based on Source Code Analysis
### Resource Conflict and Deadlock Definition  
The phenomenon of deadlock, like the race condition, the atomicity violation, and the order violation in the literature on the subject, are included in the category of errors specific for multithreaded applications. The listed errors will be listed in this work because the causes for these phenomena should be sought in the way resources are handled by parallel application threads. Resources that are shared by threads must be handled in a specific way using locks, which should also be treated as resources. Thus, incorrect resource handling is referred to as a resource conflict, where a resource conflict should be understood as a subset of structural errors occurring in the source code of a multithreaded application that causes these phenomena. In the context of the deadlock phenomenon, the basis for the conflict is the inability to gain control over the lock, which is necessary to secure the operation on the shared resource against the conflict, causing the phenomenon of race condition. The inability to gain control over the lock usually results from the wrong order of operations performed within the thread, the lack of the lock release operation, or placing the release operation in the wrong place in relation to the operation establishing the lock.  
The deadlock phenomenon has been defined as a situation in which several processes wait indefinitely for an event that can only be started by one of the waiting processes [3]. The difference between threads and processes is slight because threads operating within one process share the entire address space and other resources, while processes have their own resources and their own address spaces [4].  
In other areas where deadlock also occurs, different varieties of Petri nets (PN) are used to detect them [5]. In addition to PN, which makes deadlock detection possible, also in multithreaded applications [6], a directed graph [3] and Gadara nets are used [7], which are also a type of PN.  
In 2014, one of the articles was developed discussing the method of automatic fixing of deadlocks [8]; however, these methods met with considerable criticism [9]. The most important disadvantages of these solutions include the low quality of patches, which results from creating them based on a limited group of tests, not necessarily adequately matched to the code to be fixed [9].  
In [10], deadlocks were divided into resource deadlocks and communication deadlocks. Resource deadlocks in programming occur when processes or threads need a particular group of shared resources to work, and each of them has only selected resources, which results in waiting indefinitely [11]. The thread can wait for access to resources that it already has (see Sections 5.3 and 5.4), and this is due to the construction of a mechanism of mutual exclusion (mutex), which can be locked and unlocked.  
Communication deadlocks [10] are more abstract and more general than resource deadlocks. They occur in distributed systems, in interprocess communication, as well as in multithreaded applications, in which a cycle of waiting is created, causing deadlocks. This article does not deal with issues related to communication deadlocks; more on this topic can be found in [10,12].