Types for Atomicity

1. Types for Atomicity Presentation by Anton Wolkov for Seminar in Distributed Algorithms Spring 2013 Authors: Cormac Flanagan, UC Santa Cruz Stephen Freund, Marina Lifshin, Williams College Shaz Qadeer, Microsoft Research

2. Subject of this paper A way to simplify verification of programs with arbitrarily-interleaved threads accessing common resources by introducing an extension to the Java type system with special notations. The notation writing task itself is simplified by introducing special type inference system. Finally using a prototype checker on benchmark code we show the usefulness of this type system.

3. What problems are we addressing? Multi-threaded Java programs are hard to verify manually, because they can misbehave when non atomic operations with write operations on common resources are interleaved in unexpected ways. Even existing Java libraries exhibit subtle flaws after years of community and internal QA. We would much rather manually verify a serial execution of a multi-threaded program.

4. Race Conditions What is a race condition? A race condition occurs when two threads simultaneously access the same data variable, and at least one of the accesses is a write. A lot of work has been done in detecting these types of flaws with static and dynamic analysis and there are decent tools for detecting these errors in Java.

5. Current solutions to race condition There are methods and tools to detect race conditions in multi-threaded Java applications Is a race condition free program good enough? Is there a serial execution equivalent with the same result as any other interleaved execution? 1 C. Flanagan and S. Freund. Type-based race detection for Java. In Proceedings of the Conference on Programming Language Design and Implementation, pages 219–232, 2000.

6. What is a race condition? A race condition occurs when two threads simultaneously access the same data variable, and at least one of the accesses is a write. Race Condition (2) Is a race condition free program good enough? No. For example: acquire(l); t := x; release(l); t := t + 1; acquire(l); x := t; release(l); This code by definition is race condition free.

7. What is a race condition? A race condition occurs when two threads simultaneously access the same data variable, and at least one of the accesses is a write. Race Condition (3) acquire(l); t := x; release(l); t := t + 1; acquire(l); x := t; release(l); If this code is executed 5 times with random thread interleaving the value of x can be incremented by any value between 1 and 5. What we would like to use is a stronger term we call atomicity.

8. Introducing Atomicity Obviously we do not require the entire program to be serially executed in a multi-threaded environment, so instead we would like to have some individual methods to be safe and atomic. What is atomicity? A method is atomic if, for every execution, there is an equivalent serial execution in which the actions of the method are not interleaved with actions of other threads.

9. Introducing Atomicity Cont'd. Thread scheduler is still free to interleave but, any interaction between threads are benign or has negative affect (access to common resources is "safe").

10. In layman's terms If a method is atomic we can assume that even if it will interleaved with other code it will still act the same way it would in a serial execution. This covers race conditions but provides a stronger guarantee. Atomic Race Condition Free

11. Motivation for atomicity What is it good for? • Multi-threaded applications are prevalent. • Thread interleavings are really hard for programmers. Flaws are commonly missed during development and code reviews. • Previous efforts were invested in avoiding race conditions, but race condition free programs still may fail spectacularly in edge cases.

12. An example class Account { int balance = 0; synchronized int read() { return balance; } synchronized void set(int b) { balance = b; } void deposit (int amount) { int b = read(); set(b + amount); } }

13. An example class Account { int balance = 0; synchronized int read() { return balance; } synchronized void set(int b) { balance = b; } void deposit (int amount) { int b = read(); set(b + amount); } } If a new thread comes along and modifies balance here we will set the new balance to a wrong value.

14. An example class Account { int balance = 0; synchronized int read() { return balance; } synchronized void set(int b) { balance = b; } void deposit (int amount) { int b = read(); set(b + amount); } } This is not a race condition since we do not access balance concurrently.

15. Synchronized vs. Atomic The synchronized keyword in java is too restrictive. • An object wide statement, does not handle escapes. • Too harsh. All other synchronized methods in the object are stopped from executing (serial execution). • We would like the same bottom line without sacrificing thread interleaving completely.

16. Why a type system? Programs are large, and we don't want to check it whole. Type system provides modularity for the checker. We also want to guarantee our libraries are safe for any use.

17. Verification using keywords We introduce a formal multi-threaded subset of Java language we call AtomicJava. Each atomic method should be notated with the keyword atomic and an appropriate level of atomicity, including the conditions are locks that are in place.

18. Quick Reminder: Theory of right and left movers An action a is a right moverif for any execution where the action a performed by one thread is immediately followed by an action b of a different thread, the actions a and b can be swapped without changing the resulting state S3.

19. Theory of right and left movers Similarly, an action b is a left mover if whenever b immediately follows an action a of a different thread, the actions a and b can be swapped, again without changing the resulting state.

20. Example of an atomic method synchronized void inc() { int t = x; x = t + 1; } The keyword synchronized instructs Java to hold a lock on this for the duration of the method.

21. synchronized void inc() { int t = x; x = t + 1; } Example of an atomic method We denote the acquisition of the lock acq and rel for the release. Suppose that the actions of this method are interleaved with arbitrary actions X1, X2, and X3 of other threads

22. synchronized void inc() { int t = x; x = t + 1; } Example of an atomic method Because the acq operation is a right mover and the write and rel operations are left movers, there exists an equivalent serial execution where the operations of the method are not interleaved with operations of other threads (see illustration above). Thus the method is atomic.

23. Theory of right and left movers cont. • a lock-acquire operation is a right mover • a lock-release operation is a left mover If a variable must be held by a lock to be accessed the operation has (both) right and left movers. In Java this is true to all synchronized methods since it does both lock-acquire and lock-release operations. In short we will call right and left movers - movers.

24. Theory of right and left movers cont. More generally, suppose a method contains a sequence of right movers followed by a single atomic action followed by a sequence of left movers. Then an execution where this method has been fully executed can be reduced to another execution with the same resulting state here the method is executed serially without any interleaved actions by other threads. Therefore, an atomic annotation on such a method is valid.

25. AtomicJava We base our formal development on the language AtomicJava, a multi-threaded subset of Java with a type system for atomicity.

26. AtomicJava keywords Each field declaration includes a field guard g that specifies the synchronization discipline for that field. The possible guards are: • final- the field cannot be written to after initialization • guarded_by l- the lock denoted by the lock expression l must be held on all accesses (reads or writes) of that field • write_guarded_by l- the lock denoted by the lock expression l must be held on all writes of that field, but not for reads. • no_guard- the field can be read or written at any time. Useful to denote fields with intentional race conditions.

27. AtomicJava parameterized classes class cn<ghost x1,...,xn> { ... } Classes now have a binding for the ghost variables x1...xn, which can be referred to from type annotations within the class body. The type cn<l1,...,ln> refers to an instantiated version of cn where each xi in the body is replaced by the lock expression li.

28. AtomicJava parameterized methods atomicitytypemethodcn<ghost x1,...,xn> (t1y1t2y2 ... tmym) { ... } Defines a method methodof return type typethat is parameterized by a ghost locks x1...xn and takes arguments of types t1...tm with corresponding values y1...ym . atomicity is a keyword (like atomic) which we will define next.

29. AtomicJava parameterized methods atomicitytypemethodcn<ghost x1,...,xn> (t1y1t2y2 ... tmym) { ... } Here, we note that the atomicity a may refer to program variables in scope, including this, the ghost parameters of the containing class, and normal parameters of the method itself.

30. AtomicJava synchronized methods sync l { ... } Acquires lock l, execute the expression inside, and finally release lock l. This is similar to synchronized in "regular" Java only here we get to specify the lock (and synchronized always chooses this). A forked thread does not inherit locks held by its parent thread.

31. AtomicJava fork e.fork Starts a new thread starting with (object) e's run method with a single ghost parameter. The fork operation spawns a new thread that, conceptually, acquires a new thread-local lock tll for instantiating the ghost parameter to the method run. This lock is always held by the new thread and may therefore be used by run to guard thread-local data, and it may be passed as a ghost parameter to other methods that access thread-local data.

32. AtomicJava - everything else Other expressions in the language include field read and update, method calls, variable binding and reference, conditionals, loops, and synchronized blocks. We include basic types for both single-wordints and double-wordlongs. Only reads and writes of the former are atomic. Reads and writes of object references are also atomic.

33. Types of Atomicity - Levels • const • The atomicity const describes any expression whose evaluation does not depend on or change any mutable state. Hence the repeated evaluation of a const expression with a given environment always yields the same result. • i.e. a method returns a constant. • mover • atomic • cmpd • error

34. Types of Atomicity - Levels • const • mover • The atomicity mover describes any expression that both left and right commutes with operations of other threads. • i.e. if access to a field f declared as guarded_by land the access is performed with the lock l held. • atomic • cmpd • error

35. Types of Atomicity - Levels • const • mover • atomic • The atomicity atomic describes any expression that is a single atomic action, or that can be considered to execute without interleaved actions of other threads • cmpd • error

36. Types of Atomicity - Levels • const • mover • atomic • cmpd • The atomicity cmpd describes compound expression for which none of the preceding atomicities apply. • i.e. sequential atomic ops not guarded by a lock • error

37. Types of Atomicity - Levels • const • mover • atomic • cmpd • error • The atomicity error describes any expression violating the locking discipline specified by the type annotations.

38. Hierarchy of basic atomicity const ⊏ mover ⊏ atomic ⊏ cmpd ⊏ error

39. Sequential composition operations of atomicity levels ; (as in b;c) denotes sequential composition

40. Conditional atomicity In some cases, the atomicity of an expression depends on the locks held by the thread evaluating that expression. For instance, if we hold lock1we have a mover, otherwise we have a problem. Formal notation: (lock1 ? mover : error) A conditional atomicity (l ? a1 : a2) is equivalent to atomicity a1if the lock l is currently held, and it is equivalent to a2if the lock is not held.

41. Atomicity - Formal definition Each atomicity level can be basic or condition:

42. Atomicity closure For example: Meaning: if lock l1 is held we have a mover, if lock l2 is held but not l1 we have an atomic op, otherwise we have a violation of thread safety.

43. Atomicity levels formal notation Let b;c denote the sequential composition of b and later c Let b* denote the iterative closure of b. Let ⨆ denote the join operator based on this subatomicity ordering. If basic atomicities b1 and b2 reflect the behavior of e1 and e2 respectively, then the nondeterministic choice between executing either e1 or e2 has atomicity b1⨆b2.

44. Conditional atomicity with lock sets We denote (|b|)(ls) = b where b is a conditional atomicity and lsis a set of locks, to be equivalent to: b = l ? a1 : a2 Meaning: for every lock in the set our atomicity is a1 and a2 for every lock that is not.

45. Atomicity levels calculus Extension of iterative closure, sequential composition, and join operations to conditional atomicities

46. Theorem 1 Extension of iterative closure, sequential composition, and join operations to conditional atomicities with lock sets (|a1*|)(ls)=((|a1|)(ls))* (|a1;a2|)(ls)=(|a1|)(ls);(|a2|)(ls) (|a1⨆a2|)=(|a1|)(ls)⨆(|a2|)(ls)

47. Conditional subatomicity ordering We now extend the subatomicity ordering to conditional atomicities. Assume h is a set of locks held by the current thread and n is a set of locks not held by the current thread. Intuitively, the condition a1⊑nha2 holds if and only if (|a1*|)(ls)⊑(|a2*|)(ls) holds for every lockset ls that contains h and is disjoint from n.

48. The condition a1⊑nha2 holds if and only if (|a1*|)(ls)⊑(|a2*|)(ls) holds for every lockset ls that contains h and is disjoint from n. Conditional sub- atomicity ordering Formally, we define a1⊑a2 to be a1⊑∅∅ a and check recursively:

49. Theorem 2 For all atomicities a1and a2: a1⊑a2 ⇔ ∀ ls: (|a1|)(ls)⊑(|a2|)(ls) If a1,a2 are not conditional this is trivial because ∀ ls: (|a|)(ls) = a and a is non conditional

50. Atomicity Equivalent Atomicities a1 and a2 are equivalent (a1≡a2) if a1⊑a2anda2⊑a1 and thus: a1≡a2 ⇔ ∀ ls: (|a1|)(ls)≡(|a2|)(ls)