1. Atomicity in Multi-Threaded Programs Prachi Tiwari University of California, Santa Cruz prachi@soe.ucsc.edu CMPS 203 Programming Languages, Fall 2004

2. Race conditions: A race condition occurs if two threads simultaneously access the same shared variable and one of the access is write. Atomicity: A block of code is ‘atomic’ if for every interleaved program execution, there is an equivalent execution with same overall behavior, within which the entire block executes without preemption when method is executed serially.. Techniques for verifying atomicity: Type systems Theorem proving Dynamic analysis Model checking

3. Dynamic analysis - Atomizer : A dynamic atomicity checker for multi- threaded programs was developed as a run time verification tool to check atomicity specification. -Instead of waiting for particular interleaving on which atomicity violation causes erroneous behavior, the checker actively looks for evidence of atomicity violation that may cause error under other interleaving -This analysis combines ideas from both * Lipton theory of reduction – Proof technique for verifying atomicity using information about race condition * Lockset algorithm – identifies race conditions

4. Lipton’s Reduction Let’s denote the instructions as follows: L for left-mover, R for right-mover, N for non-mover, B for both-mover Then any execution sequence matching the following regular expression is equivalent to an atomic one: Reducible Method: (R + B)* (N +  ) (L + B)* The Atomizer implements a relaxed instrumented semantics to accommodate benign race conditions

5. Lockset algorithm If a variable is consistently protected by some lock, this lock must be held during all accesses to that variable. Tracks lockset for each field where, lockset = set of locks held Dynamically, we can look at the set of protecting locks helds during each access so far, and keep track of their intersection –If the intersection is empty, there seems to be no consistent locking discipline - classify access as a non- mover –Otherwise, there seems to be a consistent locking discipline - classify access as a both-mover

6. Lockset algorithm On first access to the files: Lockset (field) = lock(current_thread) On all subsequent access to the field: Lockset (field) = Lockset(field) ∩ lock(current_thread) Empty lockset indicates race condition Lockset(field) = { }  RACE CONDITION

7. Lockset algorithm For each filed of each allocated object, Atomizer tracks a state reflecting the degree to which the field has been shared among multiple threads. The following states come up: -Thread local, - thread local(2), - Read-shared, - shared modified.

8. method() { …. }Instrumented Source code RunTime: Lockset Reduction Atomize r Compiler WARNING Atomizer Event stream

9. IMPLEMENTATION Identify blocks that are supposed to be atomic –use heuristics exported methods synchronized methods synchronized blocks –allow user annotations stop the checking if there are false bugs do additional checks by declaring atomic /*# atomic */ void getChars() {... }

10. IMPLEMENTATION Perform instrumentation on the source code level –could also be done at the bytecode level –Instrumented source code produces event stream during execution Analyze event stream –For each block that is supposed to be atomic, check whether there is an equivalent execution in which it is scheduled contiguously. –Run the Lockset and Reduction algorithm Then, warn user if supposedly atomic block does not belong to this class.

11. Conclusion: - Atomizer detects the errors missed by the standard race detectors. -Produces fewer false alarms on benign races which do not cause atomicity violations. -Avoids the overhead of type annotations or type inferences. -Results suggest that large number of exported methods in benchmark are atomic. -Atomicity is the fundamental design principle in many multi-threaded systems.

12. Thank You