# Atomicity Violation in Multithreaded Applications and Its Detection in Static Code Analysis Process
## 3 Existing Solutions  
There are two different patents for detecting atomicity violations. The first one consists in the analysis of processor instructions and simulation of selected scenarios [17]. The second one describes a method of detecting the atomicity violation phenomenon called \"access interleaving invariants\" (AII) [12]. The method described there was originally implemented in AVIO [18] and SVD tools [19], and a few years later it was also used in the CTrigger framework [7]. [PERSON] et al. [7] also criticized the methodology of searching for atomicity violation through stress tests. Its determinism was indicated as a disadvantage of this solution. Although multithreaded applications are only seemingly non-deterministic, it is precisely this apparentness that makes it impossible to cover all possible states of a multithreaded application with deterministic tests. The process of static analysis of the code for searching for atomicity violations has also been criticized, indicating that these methods report _false-positive error_ in many places [7; 20]. As a solution to this problem, it has been suggested to perform tests or use separate tools to investigate _false-positive error_[7]. It was also pointed out that there are scenarios in which CTrigger requires huge resources and has to work many hours to detect the phenomenon of atomicity violation. _For example, 100 different 1-h (within CTrigger) input tests and 10 different configurations would take CTrigger 2 days to complete testing on 20 machines, while stress tests would take between 20 and even 2000 days to achieve a similar ability to expose atomicity violation that is far too long to be acceptable_[7]. Although two days of operation of 20 machines seems a better solution compared to the stress tests, it is still unacceptable in most projects. The process of static code analysis, in order to detect atomicity violation conflicts, should be much faster and cheaper compared to long-term analysis of application behavior. Despite the imperfections of such a process and many _false-positive errors_ reported, a programmer should be able to verify a false report. [PERSON] and [PERSON] [9] presented the Atomizer tool. Despite promising results, the authors of Atomizer decided to focus on hybrid methods that combine static code analysis with the \"on-the-fly\" analysis method they developed. The use of the method based on a system of types was repeated by another team [21]. [PERSON] et al. [21], as with the authors of Atomizer, bypassed one of the limitations of the developed method, so that it is no longer limited to the compilation process. The authors also mention that this method allows us to omit some conflicts that cause atomicity violation, but instead the amount of _false-positive error_ is marginal. [PERSON] et al. [22] developed a model called \"trace-based symbolic predictive model\", which was used to develop a mixed method based on tracking specific application execution paths and analyzing the source code of that application to detect an atomicity violation. The authors claim that the method presented by them does not report any _false-positive error_, but they do not guarantee that all conflicts causing the atomicity violation are detected. Solutions based on the analysis of the application during its operation, to avoid the phenomenon of atomicity violation, are applied regardless of the language in which the programs are written. With the growing popularity of JavaScript [23], this language experienced the use of Node.js runtime environment, which is used for writing server applications. In this environment, applications are created with the help of an event programming paradigm, in which many operations are performed in parallel in different threads [24]. However, this environment does not provide tools for marking operations as atomic [24]. Nor does Rust, which was developed for secure multithreading and published in 2010 [25].