Safety

1. Safety

2. system designing for concurrent execution environments • system: collection of objects and their interactions • system properties: • Safety - nothing bad ever happens • Liveness - anything ever happens at all • Correctness - system does what it was meant to • Reusability- objects can be reused in several systems without changes to code • Performance- intended activity eventually completes

3. Safety • nothingbad should ever happen to an object - preserve objects’ consistency • object remains consistent? • something bad happens? • formal definition of safety? • type safety • multi-threaded safety.

4. Type Safety • Java - statically typed language: type variable is known at compilation time • Type safety: object referenced by variable is of a type compatible with variable type (class, sub-class, interface) • compiler verifies type safety for us: • assign string value to integer variable (compiler error)

5. language constructs for generic code

6. get() and add()  work and return object of classObject • at compilation time type ofo is unknown • vector collection - as reusable as possible • no type safety

7. Generics • generics - extra argument for standard containers • express programmer intention • can be used in any class • type-safety

8. Catching errors as early as possible • compile cleanly • runtime exception • cannot cast Object to Integer • compile error •  _intVeccontains only Integers (or extending class)

9. Type safety rules • Always use generics. • Do not use casts, unless you know what you are doing… • If using casts, always use instanceof to make sure cast type is correct • Java 1.5 • supports generics • warning if you don’t use generics with containers • respect the compiler warnings and fix them

10. Multi-Threaded Safety

11. safety preservation: ensuring objects are in consistent states concurrency control: disabling of access due to actions by other threads.

12. Multi-Threaded Safety • type safety can be checked by compilers • multi-threaded safety - design classes carefully: • what are pre & post conditions and invariant of the class

14. class Even • consistency of class state: • even counter at all times • operation: increment counter

15. Pre/Post-conditions, Invariants • Invariant - object property (statement) regarding its internal state • hold throughout the lifetime of the object. • classEven: internal counter must always remain even • counter might be changed during actions on (or by) the object

16. Pre/Post-conditions, Invariants • Pre/Post conditions (PnPC) – statements about internal state of the object • hold just before and right after a method invocation (action performed on/by the object) • class Even: precondition of add():counter is even • postcondition: counter is even. • postcondition: counter has been incremented

18. Consistency and Computation • inv, pre, post : • object is in consistent state • computation is correct • what programmer intends • method is supposed to achieve.

19. system = collection of interconnected objects • structured collection

20. Object/messages abstract model – reminder* • sequence of messages received by an object: • Receive a message • Dispatch the message to a method • Execute the body of the method as a reaction • Send messages to other objects • internal state - fully encapsulated • Only object can update its own internal state

21. computation = sequence of transitions • object is first constructed • class constructor responsibility for consistent state (constructor exits, @inv holds). • object receives a message = a method is invoked • check method's @pre (not holds – computation invalid) • method completes • check method's @post (not holds – computation invalid) • execution of the method has moved the object from one internal state Si to the next internal state Si+1.

22. Formal notation • For a given computation, object moves from states S1, S2, … Sn • At each transition, the @inv condition must hold • formally: for all i, @inv(Si) holds. • transition Si–m–>Si+1 object processes message m • @pre(m)(Si) holds • @post(m)(Si+1) holds

23. overall correctness condition for a system of objects is that all objects computations are correct • NOTE 1: while a method is executing, no constraint that @inv remains enforced. • Even counter class: in the middle of the execution of the add() • object remains consistent between invocation of methods • NOTE 2: what is correct computation for a system of objects? • each object‘s correct computation sequence is only a part

24. Dangers of Concurrent Execution • code correctness? • all computations involving this code are correct • in sequential RTE: • analyze each method • check all potential execution paths • make sure the @inv, @pre and @post hold • in the hybrid execution model?

26. run: • 2 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 38 40 …Even class is not thread safe

27. Investigation • at some point in each thread's execution, the thread is preempted by the environment in favor of another thread (either in the same process or a different process)… • the preemption may take place any time during the execution of the thread…

28. Investigation • add()  - performs many more actions than you can see…

29. Investigation • pseudo JVM code: • execution of any thread may be interrupted at any line…

30. Investigation

31. After the first thread finishes first add(),  counter_ = 2 • After the second thread finishes the first add(), counter_ =  5

32. Reapair? @pre, @post and @inv hold

33. interleaving of execution Assume counter_ = 2 at time t0 T1 executes line 1 and is interrupted. (c == 2 / @pre holds) T2 executes line 1 and is interrupted. (c == 2 / @pre holds) T1 executes lines 2 and 3 (c == 4 / @post holds / @inv holds) T2 executes lines 2 and 3 (c == 4 / @post holds / @inv holds)

34. same object - shared between 2 threads (T1, T2) • object executes the method add() twice – state of the object is incremented only once. • local constraints (@inv / @pre / @post) never failed. T1 thinks all is fine. T2 thinks all is fine. • your bank account is wrong!!! • "something wrong happened" • but our formal tools cannot tell us what.

35. Global Criterion on Computation Correctness The (finite) concurrent execution of a program is correct iff: • object correctness criteria @inv @pre@post • end of computation (linearizability): • system is in one of the states that could have been reached by a sequential execution • sequence of states reached by each object could have been reached by a sequential execution

36. example • system includes one object with a single integer variable initialized at value 0. • object has 2 methods; • inc3 adds 3 to the state • inc8 adds 8 to the state • program includes invocations: inc3 , inc8 • sequential executions paths are: (0, 3, 11) or (0, 8, 11). • If a concurrent execution leaves the object in state 3 or 8 - overall computation not be correct: missed steps of computation • Strong correctness constraint: looks at all possible sequential executions of the program and objects • not fool-proof: if(i> 0) i+=8

37. Understanding What Went Wrong • a class which is correct in a sequential RTE, but incorrect in a concurrent RTE • concurrent RTE - extra-effort to ensure correctness

38. Understanding What Went Wrong • in the hybrid model: • smallest steps of the computation are not single method execution • instructions executed by the JVM, at the instruction set level

39. example: abstract computation system  Sequences transitions from object perspective: • O1: S11 --m1--> S12 --m2--> S13 • O2: S21 --n1--> S22

40. example: abstract computation system  • sequential model RTE: 3 transitions ordered relative to each other into a single execution • Dependency: which object sends which message to whom? • If no dependency - all possible interleaving S11 S12 S13 S21 S22 S11 S12 S21 S13 S22 S11 S12 S21 S22 S13 S11 S21 S12 S22 S13 S11 S21 S22 S12 S13 S21 S11 S22 S12 S13 S21 S22 S11 S12 S13

41. message n1 is sent by O1 during the execution of m2 • additional ordering constraint  S22 > S12 • O1: S11 --m1--> S12 --m2--> S13 • O2: S21 --n1--> S22 S11 S12 S13 S21 S22 S11 S12 S21 S13 S22 S11 S12 S21 S22 S13 S11 S21 S12 S22 S13

42. message n1 is sent by O1 during the execution of m2 • If there is a dependency • less possible total orderings in the sequential execution

43. safety in concurrent RTEs: • reduce scheduling of primitive state transitions among passive objects • serialization constraints among independenttransitions

44. Safe Concurrent Programming Ingredients thread-safe: • Immutability - avoiding state changes: • Eliminating the need for some exclusion control by ensuring that methods never modify an object's representation, so that the object cannot enter inconsistent states.

45. Safe Concurrent Programming Ingredients thread-safe: • Synchronization - dynamically ensuring exclusive access • Dynamically ensuring that only one thread at a time can access object state, by protecting objects with locks and related constructs.

46. Safe Concurrent Programming Ingredients thread-safe: • Containment - Structurally (using design patterns for) ensuring exclusive access • Structurally ensuring that only one thread (or only one thread at a time) can ever use a given object, by hiding or restricting access to it.

47. Immutable Objects If an object cannot change state, then it can never encounter conflicts or inconsistencies when multiple activities attempt to change its state in incompatible ways!

48. immutable object  - object whose state cannot be modified after it is created. • mutable object - can be modified after it is created

49. most simple and elegant solution for thread safety • no thread may change the internal state of the object • cost: at designstage • change = re-factoring large parts of code

50. Factory: