Shades of Atomicity in Object-Oriented Programming

1. Introduction • Programming model • Shades of Atomicity • Conclusions Questions Shades of Atomicity in Object-Oriented Programming Arnd Poetzsch-Heffter Software Technology Group University of Kaiserslautern

2. 1. Introduction

3. 1. Introduction: Speakers background • Modular specifation & verification of OO-programs • Specify properties of software units: • language-dependent (e.g. no NullPointerException, thread-safe) • program-dependent (e.g. behavior of a particular method) • Verify that implementation satisfies the properties. • Modularity is hard to achieve in OO-programming. Definition of component [Szyperski: Component Software, 2nd ed., p. 41]: "A software component is a unit of composition with contractually specificied interfaces and explicit context dependencies only. ..."

4. 1. Introduction: Specification example class interface ObservableGame { ... ObservableGame() ... void move( MoveDescr md ) requireslegal(md,currentPos) behavior currentPos = doMove(md,currentPos); forall( o in gameObs ) { o.stateChanged() } forsome( cmd : legal(cmd,currentPos) ) { currentPos = doMove(md,currentPos); forall( o in gameObs ){ o.stateChanged() } } ensuresunchanged([player,state,gameObs]) void swapPlayers() ... Position readPos() ... void register( Observer go ) ... }

5. 1. Introduction: Concurrent programming in Java (1) Let r1, r2 be thread-local, x, y be thread-shared variables. Original code: Thread 2 executes: Thread 1 executes: r2 = x; y = 1; r1 = y; x = 2; Initially: x == y == 0. Can this result in r2 == 2 and r1 == 1 on termination?

6. 1. Introduction: Concurrent programming in Java (2) It can!Compiler may transform the statements so that: Thread 2 executes: Thread 1 executes: y = 1; r2 = x; r1 = y; x = 2; Cannot happen if program is correctly synchronized!!

7. 1. Introduction: Correct synchronization Explanation: (Correctly synchronized) • A program execution is sequentially consistent iff • all individual actions are totally ordered, • the order is consistent with the program order, • each action is atomic, and • each action is immediately visible to all threads. • A program execution contains a data race iff there are • two conflicting accesses that are not ordered by the • happens-before relation. • A program is correctly synchronized iff all • sequentially consistent executions are free of data • races.

8. 1. Introduction: Goals • More structured & higher level programming models • for concurrency • Checking techniques • Simpler program-independent specifications: • atomicity • thread safety • ... • Compilation support

9. 1. Introduction: Thread safety Explanation: (Thread safety) • A piece of code is thread-safe if it functions correctly during • simultaneous execution by multiple threads. • thread-safe - the user never needs to obtain a lock explicitly for • single-call operations, but does need to obtain a lock during • multiple-call operations. • thread-compatible • thread-hostile • conditionally thread-safe

10. 2. Programming Model

11. 2. Programming model: Structuring dimensions • Dimensions: • Static  Program text • Dynamic • - Time  Execution order • - Space  Variable state In OO-programming the object structure is important.

12. Aggregate object: :List array: size: :Array … length: 0: 1: 2: … 2. Programming model: Object structures (1) Simple object: :Point x: y:

13. 2. Programming model: Object structures (2) Multiple-access object: list header iterator List Environment

14. 2. Programming model: Filesystem file system File system boundary Environment

15. Board Machine ObservableGame 2. Programming model: Compound objects Communicating compoundobjects: GameObserver GameObserver ObservableGame GamingSystem

16. 2. Programming model: Goal refined • Use the structuring into compound objects as backbone to: • provide a notion of correctness: • Invariants have to hold when execution is outside the • compound object. • define notions of atomicity and synchronization

17. 3. Shades of Atomicity

18. 3. Atomicity: Startup Atomicity in programming refers to isolation. Explanation: (Method atomicity) A method is atomic if for every (arbitrarily interleaved) program execution, there is an equivalent execution with the same overall behavior where the method is executed serially, that is, the methods execution is not interleaved with actions from other threads. [Flanagan, Freud. Atomizer: A Dynamic Atomicity Checher For Multithreaded Programs. PoPL’04] • Remarks: • what about newly created threads • non-modular  thread-locality

19. 3. Atomicity: Weak object atomicity Explanation: (Weak object atomicity) Method segments within compound objects are atomic. Guarantee: Object invariant holds.

20. 3. Atomicity: Object atomicity Explanation: (Object atomicity) Method execution segments within compound objects are atomic. Guarantee: Method call on object controls state, in particular for reentrant calls.

21. 3. Atomicity: Object protocol atomicity Explanation: (Object protocol atomicity) Object protocol atomicity generalizes object atomicity to specified sequences of method calls (object protocols). • Examples: • Creation of iterator, usage of iterator • TOCTTOU scenario

22. 4. Questions

23. 4. My Questions • What can be learned from other areas? • What are good language concepts and constructs • to capture such models? • Does this lead to a checkable notion of thread safety? • What are the consequences for modular reasoning? • ... Your Questions