Safety 1
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 2
Safety nothing bad should ever happen to an object - preserve objects consistency object remains consistent? something bad happens? formal definition of safety? type safety multi-threaded safety. 3
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) 4
language constructs for generic code 5
get() and add() work and return object of class Object at compilation time type of o is unknown vector collection - as reusable as possible no type safety 6
Generics generics - extra argument for standard containers express programmer intention can be used in any class type-safety 7
Catching errors as early as possible compile cleanly runtime exception cannot cast Object to Integer compile error _intvec contains only Integers (or extending class) 8
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 9
Multi-Threaded Safety 10
safety preservation: ensuring objects are in consistent states concurrency control: disabling of access due to actions by other threads. 11
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 12
13
class Even consistency of class state: even counter at all times operation: increment counter 14
Pre/Post-conditions, Invariants Invariant - object property (statement) regarding its internal state hold throughout the lifetime of the object. class Even: internal counter must always remain even counter might be changed during actions on (or by) the object 15
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 16
17
Consistency and Computation inv, pre, post : object is in consistent state computation is correct what programmer intends method is supposed to achieve. 18
system = collection of interconnected objects structured collection 19
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 20
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 S i to the next internal state S i+1. 21
Formal notation For a given computation, object moves from states S 1, S 2, S n At each transition, the @inv condition must hold formally: for all i, @inv(s i ) holds. transition S i m >S i+1 object processes message m @pre(m)(s i ) holds @post(m)(s i+1 ) holds 22
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 23
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? 24
25
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 26
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 27
Investigation add() - performs many more actions than you can see 28
Investigation pseudo JVM code: execution of any thread may be interrupted at any line 29
Investigation 30
After the first thread finishes first add(), counter_ = 2 After the second thread finishes the first add(), counter_ = 5 31
Reapair? @pre, @post and @inv hold 32
Assume that next interleaving of execution between T1 and T2: 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) 33
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. 34
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 35
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 2 invocations: inc3 and 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 36
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 37
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 38
example: abstract computation system Sequences transitions from object perspective: O1: S11 --m1--> S12 --m2--> S13 O2: S21 --n1--> S22 39
example: abstract computation system sequential model RTE: 3 transitions ordered relative to each other into a single execution 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 40
message n1 is sent by O1 during the execution of m2 If there is a dependency less possible total orderings in the sequential execution additional ordering constraint S22 > S12 S11 S12 S13 S21 S22 S11 S12 S21 S13 S22 S11 S12 S21 S22 S13 S11 S21 S12 S22 S13 41
safety in concurrent RTEs: reduce scheduling of primitive state transitions among passive objects serialization constraints among independent transitions 42
Safe Concurrent Programming thread-safe: Ingredients 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. 43
Safe Concurrent Programming thread-safe: Ingredients 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. 44
Safe Concurrent Programming thread-safe: Ingredients 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. 45
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! 46
most simple and elegant solution for thread safety no thread may change the internal state of the object at the design stage change = re-factoring large parts of code 47
48
implementation of Even is immutable - new object of this class, its internal state may not change - ever object is always safe, even in concurrent execution environments 49
How to create immutable objects Don't provide "setter" methods. Make all fields final and private. Don't allow subclasses to override methods. declare the class as final make the constructor private and construct instances in factory methods. If the instance variables (members) include references to mutable objects, don't allow those objects to be changed: Don't provide methods that modify the mutable objects. Don't share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods. Immutable instance variables are always initialized during construction. 50
Immutable objects are possibly applicable when: Object serves as instances of a simple abstract data type representing values. For example: colors, numbers, strings. different classes supporting different usage can be designed, one immutable and the another updatable. java.lang.string is immutable while java.lang.stringbuffer is updatable. benefit of never needing to protect the object outweighs the cost of copying the object each time it needs to be changed. copying technique is popular and is valid. trade-off: readability and execution time Java does not support pass-by-copy for non-scalar types. copy by another assignment. in some RTE (not Java though), the actual copying may be delayed to the moment a change occur to the variable, thus saving execution time in some scenarios. multiple objects representing the same values (for a reason not related to safety) 51
helper classes 52
Stateless methods Another aspect of immutability are stateless methods. A stateless method is a method that does not change the object state. provide services 53
Publish and Escape: behavior and implementation of classes Publish internal state of an object is published if it is accessible from outside the object. Example: a public member. By definition, this member is published as soon as the object is created. Example: a private member to which a reference is returned by a public method call, e.g., a private Vector that is returned in a public getter. published members must be protected be immutable locks 54
Publish and Escape: behavior and implementation of classes Escape internal state of an object has escaped if a reference to the internal state of the object is available outside of the object inadvertently. Example: returning a reference to an internal member of an immutable object avoid 'this' to escape during construction of an object (otherwise, other objects could access the object before it has reached a valid state). 55
Design Patterns general reusable solution to a commonly occurring problem in software design. description or template for how to solve a problem that can be used in many different situations. 56
Example 1: Observer design pattern Object register itself to some event source and be notified each time something happens Example: a vector can notify each time a modification happens (element added/removed). 57
EventListenerImpl : object who would like to be notified on events of the EventSource 58
'this' of EventListener escaped during construction of the class. danger: exposing an incompletely constructed EventListener object to other threads: Once registered, eventsource can call the onevent() method although the class has not yet been constructed 59
60
In example 2 'this' escaped implicitly. A reference to the object under construction is being published in this case indirectly where another thread can see it. When creating the new InnerListener it received 'this' of EventListenerImpl2 how would it be able to call the eventreceived method? 61