# Atomicity Violation in Multithreaded Applications and Its Detection in Static Code Analysis Process
## 2 Description of the Phenomenon  
The phenomenon of atomicity violation is a result of inconsistent order of access to data [11] as shown in Figure 1. Most often it refers to a situation in which the programmer intended to execute two instructions in series, excluding other instructions with access to a shared memory area, and yet another instruction affects the memory area of these two functions [12]. In this work atomicity violation is a phenomenon resulting from violating the execution of a pair of operations (forming a logical whole) on the shared resource, by an operation of another thread operating on that resource. These operations in the source code of the program do not have to occur directly after each other--i.e., there may be other operations between them that do not affect the shared resource in any way. The operation is to be understood as any C language instruction. The phenomenon of atomicity violation can be described as a situation in which there is a scenario of two threads working, the course of which deviates from the scenario expected by the programmer. The phenomenon of atomicity violation is closely related to the phenomenon of race condition, because in both cases both threads should be mutually exclusive when working on a shared resource. The exclusion of threads takes place by placing the operations performed on the resource in the critical section, where the critical section is understood as a set of operations performed between the locking and unlocking mutex. In [13], the atomicity violation phenomenon is also called \"high-level data races\". However, in the case of atomicity violation, the critical section should include a pair of operations carried out on a shared resource. In both cases, however, the order in which the operations are performed affects the final result. Figure 1: Visualization of the atomicity violation phenomenon. Source [14]. It can also be said that the phenomenon of race condition is a special case of atomicity violation. This is because there are instructions in C and C++ languages, which at the programming language level are atomicity operations--i.e., consisting of one language instruction (e.g., an incrementation operation). However, the situation changes when the code is compiled. _The time needed to retrieve a word value from memory to cache and then to register can be (in terms of processors) very long. At best, about 500 instructions can be executed before the value reaches the registry, and it will take the same amount of time to pass the new value to its destination_[15]. When the atomicity violation occurs at the programming language level, the symptoms may include:  
1. Undefined application behavior;
2. Incorrect application behavior. In works on atomicity violation, a thread in which a pair of operations is performed (to form a logical whole) is called local, and a thread with a violating operation is called the remote thread. [PERSON] and [PERSON] [16] describing the phenomenon of atomicity violation, stress that this phenomenon may be required, harmless and undesirable [16]. An example of a required violation of atomicity is a situation in which two threads communicate by passing information using a shared resource. This example is a part of the scenario described in the first column in the second row of Table 1. However, this example is incorrect because the pair of operations of the local thread requires a record operation in the remote thread to work correctly. To sum up, the example scenario described by [16] does not meet one of the conditions of atomicity violation--i.e., the remote operation does not interfere with the work of local pair of operations. On the contrary, if the remote thread records are not performed, the local thread will be affected. Therefore, it seems reasonable to question the claim that there are scenarios in which atomicity violation is required. If two operations in the indicated memory area are to be performed without any interference, the interference may be neutral or undesirable.