# On-the-Fly Repairing of Atomicity Violations in ARINC 653 Software
## 5 Experiments
### Synthetic Programs  
There are four reasons for using a synthetic program. First, even though a program is tested with static and dynamic debugging tools to find and fix the bugs, there are latentbugs which are not discovered. We developed ARINC 653-compliant synthetic software that runs in an ARINC 653 environment. This is common practice because the effect of these bugs is very difficult to reproduce. Second, as the code size increases, the probability of atomicity violations decreases. It is because there is a high probability that critical sections avoid exhibiting atomicity violations. Thus, to reproduce and accelerate the debugging process, we used a synthetic program that models the critical sections. Third, atomicity violation is prevalent both in airborne software and general-purpose software. We analyzed atomicity violation patterns in different software types. The final and most critical reason why we used a synthetic program is because airborne software codes are proprietary and are not open to the public. To test the proposed RAV, we modeled five atomicity violation patterns prevalent in real-world software and developed five synthetic programs for the ARINC 653 simulator. These synthetic programs were implemented as ARINC 653-compliant software that runs in an ARINC 653 environment. In the ARINC 653 operating system, these synthetic programs were loaded and executed in one partition. We did not consider the case of multiple partitions because the scope of this work is to repair atomicity violations in an intra-partition. It has to be noted that 97% of concurrency errors in real-world software are observed while two threads are executing [3]. We designed a synthetic program that ran two threads to create atomicity violations. We only included access events on a single shared variable without nested parallelism nor locks. The five types of atomicity violations are described in Table 2 using bug reports on MySQL [44], Mozilla [45], Apache [46] and Ardupilot [47]. In the pattern, \"R\" and \"W\" denote read and write events, respectively. \"[\" and \"]\" denote the beginning and the end of a region, respectively, that must be protected by a lock. We used \"\(\parallel\)\" to express the concurrent execution of threads. In the code shown in Figure 6a, thread1() acquires lock and performs write and read operations, which is denoted as \(T_{i}^{[W-R]}\); thread2() runs without any protection and can be denoted as \(T_{j}^{\text{W}}\). Since the two threads can be concurrently executed, we use \(T_{i}^{[W-R]}\parallel T_{j}^{\text{W}}\) to represent this behavior. Figure 6 describes the source code and the result of the code that executes \(T_{i}^{[W-R]}\parallel T_{j}^{\text{W}}\). The initial value for the shared variable is 0. thread 1 updates the shared variable (sv = 1), then checks the shared variable (sv = 0) to update the local variable. thread 2 updates the shared variable (sv = 0). The program should not execute the conditional statement (line 11) because line 8 (sv = 1) of thread 1. However, as can be seen from the result shown in Figure 6b, the conditional statement in line 11 is executed and the text lv: 1 is printed. In this case, the atomicity is violated where sv = 0 (line 19) of thread 2 executes after sv = 1 (line 8) of thread 1. The result shows that there were five atomicity violations during the life of this short example.