# Atomicity Violation in Multithreaded Applications and Its Detection in Static Code Analysis Process
## 4 Agreement Relationships between Operations  
Relationships between operations, which can be read from the source code of any language, are limited to the order in which the operations are performed. According to the definition, the phenomenon of atomicity violation is a result of a violation of an operation pair on a specified memory area--i.e., on a shared resource occupying a specified area. It is not a disruption of the order of these operations, so one may suspect that there is a certain relationship between the pair of operations that is being violated; as a result of which, the program does not work properly. As a result of the analysis of the atomicity violation phenomenon, three relations have been developed, the violation of which leads to the atomicity violation phenomenon. Thus, if a program has two operations \(a\) and \(b\), where \(a\prec b\) and these operations form a logical whole, the following relationships may occur between these operations:  
* Forward--a relationship in which the operation \(a\) always must be followed by an operation \(b\);
* Backward--a relationship where operation \(a\) always has to precede operation \(b\);
* Symmetric--a relationship where operation \(a\) always has to precede operation \(b\), and operation \(b\) always has to follow operation \(a\). Despite a large number of studies on the phenomenon of atomicity violation, none of the works discuss the relationship between operations. The existing programming languages do not have any mechanisms that would allow for the declaration of such relations. However, the programmer may use a locking mechanism which allows one to secure the desired operations from violating the relations. Complementing the source code with information about these relationships should allow for faster locating of the atomicity violation during the static code analysis process, or at least reduce the number of _false-positive errors_ reported. An alternative solution is to enrich the process of converting the code into a model with the possibility of accepting such data as an input. In the review of literature and technical docs, no mechanism has been found so far in programming languages, by means of which it is possible to declare the relations presented in this point. Knowledge about relations can be found in libraries' documentation or by asking programmers, and that is why they are referred to as agreement relationships. Lack of knowledge of the relationships developed is the reason why programmers do not understand the phenomenon of atomicity violation. If these relationships could be defined by means of programming language mechanisms, it would be much easier to locate atomicity violation. It is therefore reasonable to draw up a new definition which will have information about the relationships whose disruption cause phenomenon of atomicity violation. Pairs of operations in relation to each other may be located by the Kivati program as components of atomic regions which are located for dynamic analysis. In the proposed solution, instead of checking how the code of the atomic regions works, the structure of the code is more important. It allows for checking only the related operation pairs and skips other operations which speed up process of analysis. Taking into account the mentioned gap in the literature, it is worth presenting the following definition of the phenomenon of the atomicity violation. **Definition 1**. : _Atomicity violation is a phenomenon in which there is a relationship between two operations \((o_{i,j},o_{a,b})\) of one thread, using a common resource \(r_{c}\), whose disruption caused by the operation of another thread on the same resource (unexpected change of resource value) results in the undefined behavior of the algorithm using those operations._  
The operations should be understood as instructions or functions called in the program code.