# Atomicity Violation in Multithreaded Applications and Its Detection in Static Code Analysis Process
## 1 Introduction  
Software errors exist as long as the software itself. The cause of most errors in multithreaded applications is the so-called resource conflict, while the result is undesirable phenomena, such as race condition. Race condition and deadlock are by far the most common phenomena that occur in multithreaded applications. In comparison to the phenomenon of atomicity violation, race condition and deadlock are easy to locate. They result directly from the code structure of the application [1; 2], as opposed to the atomicity violation phenomenon, which is detailed in Section 4. However it was important to start studies on atomicity violation, and they had to be started from less complicated phenomena. Race condition and deadlock were the best case study. Race condition and atomicity violation belong to these same type of phenomena and the incorrect fixing of both of them may lead to deadlock. In other words resolving the problem with race condition phenomenon and deadlock phenomenon allow for a better understanding of how to fix data race errors and without adding new ones.  
Multithreading is one of the basic mechanisms for parallel computing, which is possible on one processor and on several processors [3; 4]. It is used very often in utility applications (mentioned in the rest of the work), but also in scientific research [5]. Popular, commonly used open-source multithreaded applications are a very good source for research on undesirable phenomena in multithreaded applications. In a popular Apache server, atomicity violations have been located several times, with the examples described in the works concerning buffer handling [6; 7]. The effect of an incorrectly written function was, in the worst case scenario, the unexpected termination of the application. The situation was similar for the MySQL relational database management system. The state of the log file was stored in the form of a global variable, which was used by several operations [6] constituting a logical whole.  
The problem of atomicity violation concerns not only open-source programs. Various JDK packages were also tested and in version 1.4.2 of this package it was discovered that the handling of five popular containers had errors in its implementation that caused the atomicity violationphenomenon [8]. Four years earlier, a conflict causing an atomicity violation was discovered in a _StringBuffer_ implementation in the Java standard library [9]. Despite the high popularity of Java, frequent use in created network projects [10], or huge support from the community, the above examples show how important it is to avoid multithreading errors. This then forces developers to look for solutions to optimize their code to help them prevent these phenomena.  
The development of static code analysis method for detecting phenomenon of atomicity violation is important for a few reasons. First of all, testing and dynamic methods known from the literature are insufficient. Effective static analysis can be part of the compiling process, because it is easy to convert Abstract Syntax Trees into any other representation and make an architecture check. Dynamic analysis can affect applications during working and can add other hard-to-find errors. On the other hand, fixing bugs in the code allows us to use every compiler instead of those introducing mechanisms for dynamic analysis.  
The next section contains a detailed description of the atomicity violation phenomenon. Section 3 describes known methods and programs that allow for detecting the atomicity violation phenomenon. Section 4 contains a description of relations whose violation causes the atomicity violation phenomenon. This is the original part of research on this phenomenon. Section 5 provides information about how the source code model of multithreaded applications has been extended to detect the atomicity violation phenomenon. The problem was formulated in Section 6 preceding Section 7 with a sufficient condition. Sections 8 and 9 contain a leading example and a summary, respectively.