Rollback Atomicity Serdar Tasiran and Tayfun Elmas Koc University, Istanbul, Turkey Abstract. We introduce a new non-interference criterion for concurrent programs: rollback atomicity. Similarly to other definitions of atomicity, rollback atomicity of a given concurrent execution requires that there be a matching serial execution. Rollback atomicity differs from other definitions of atomicity in two key regards. First, it is formulated as a special case of view refinement. As such, it requires a correspondence between the states of a concurrent and a serial execution for each atomic block rather than only at quiescent states. Second, it designates a subset of shared variables as peripheral and has more relaxed requirements for peripheral variables than previous non-interference criteria. In this paper, we provide the motivation for rollback atomicity. We for- mally define it and compare it with other notions of atomicity and non- interference criteria. We built a runtime checker for rollback atomicity integrated into the refinement checking tool, VYRD. This implemen- tation was able to verify that concurrent executions of our motivating example are rollback atomic. 1 Introduction Shared-memory multi-threaded programs are prone to concurrency-related bugs. In addition to program-specific correctness properties, several generic correctness and non-interference criteria have been studied for such programs, including freedom from race conditions and deadlocks. Such generic criteria provide a separation of concerns. By first verifying or trying to ensure that his program does not violate a generic correctness criterion, a programmer can then make certain assumptions and simplify his reasoning while ensuring other properties of the program. For instance, for Java programs, ensuring race freedom allows the programmer to assume sequential consistency for his program [9]. A higher-level correctness criterion that is frequently used is atomicity. Pro- grammers designate blocks of their code atomic and would like to have certain mutual-exclusion and non-interference guarantees about such blocks. A program- mer may ensure the atomicity of code blocks himself using synchronization con- structs provided by the platform he is working on, or he may use a transactional memory implementation to ensure atomicity [8]. Several different variations of atomicity have been defined and investigated in the literature. In this study, we propose and investigate a new notion of atomicity called rollback atomicity that addresses certain limitations of existing definitions of atomicity. Definitions of atomicity have the following general form: Definition 1 (Atomicity). A concurrent execution σ conc of a program is atomic iff there exists an equivalent, serial execution σ ser in which actions of each atomic block are executed consecutively.