SPL/2010 Safety 1

SPL/2010 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

SPL/2010 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

SPL/2010 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

SPL/2010 language constructs for generic code 5

SPL/2010 ● 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

SPL/2010 Generics ● generics - extra argument for standard containers ● express programmer intention ● can be used in any class ● type-safety 7

SPL/2010 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

SPL/2010 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

SPL/2010 Multi-Threaded Safety 10

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

SPL/2010 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

SPL/

SPL/2010 class Even ● consistency of class state: ● even counter at all times ● operation: increment counter 14

SPL/2010 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

SPL/2010 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

SPL/

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

SPL/2010 system = collection of interconnected objects ● structured collection 19

SPL/2010 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

SPL/2010 computation = sequence of transitions ● object is first constructed ● class constructor responsibility for consistent state (constructor holds). ● object receives a message = a method is invoked ● check (not holds – computation invalid) ● method completes ● check (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

SPL/2010 Formal notation ● For a given computation, object moves from states S 1, S 2, … S n ● At each transition, condition must hold ● formally: for all i ) holds. ● transition S i –m–>S i+1 object processes message m i ) holds i+1 ) holds 22

SPL/2010 ● overall correctness condition for a system of objects is that all objects computations are correct ● NOTE 1: while a method is executing, no constraint 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

SPL/2010 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 hold ● in the hybrid execution model? 24

SPL/

SPL/2010 ● run: ● …Even class is not thread safe 26

SPL/2010 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

SPL/2010 Investigation ● add() - performs many more actions than you can see… 28

SPL/2010 Investigation ● pseudo JVM code: ● execution of any thread may be interrupted at any line… 29

SPL/2010 Investigation 30

SPL/2010 ● After the first thread finishes first add(), counter_ = 2 ● After the second thread finishes the first add(), counter_ = 5 31

SPL/2010 hold 32

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

SPL/2010 ● same object - shared between 2 threads (T1, T2) ● object executes the method add() twice – state of the object is incremented only once. ● local constraints 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

SPL/2010 Global Criterion on Computation Correctness The (finite) concurrent execution of a program is correct iff: ● object @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

SPL/2010 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 36

SPL/2010 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

SPL/2010 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

SPL/2010 example: abstract computation system Sequences transitions from object perspective: ● O1: S11 --m1--> S12 --m2--> S13 ● O2: S21 --n1--> S22 39

SPL/2010 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 40

SPL/2010 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 41

SPL/2010 message n1 is sent by O1 during the execution of m2 ● If there is a dependency ● less possible total orderings in the sequential execution 42

SPL/2010 ● safety in concurrent RTEs: ● reduce scheduling of primitive state transitions among passive objects – serialization constraints among independent transitions 43

SPL/2010 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. 44

SPL/2010 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. 45

SPL/2010 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. 46

SPL/2010 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! 47

SPL/2010 ● immutable object - object whose state cannot be modified after it is created. ● mutable object - can be modified after it is created 48

SPL/2010 ● most simple and elegant solution for thread safety ● no thread may change the internal state of the object ● cost: at design stage ● change = re-factoring large parts of code 49

SPL/2010 Factory: 50

SPL/2010 ● Static methods - use no instance variables of any object of the class they are defined in. ● cannot access any instance variables. ● can access static variables 51

SPL/2010 immutable Even ● new object of Even - its internal state may not change - ever ● object is always safe, even in concurrent execution environments 52

SPL/2010 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. 53

SPL/2010 How to create immutable objects? ● 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; ● Create copies, and store references to copies. ● Create copies of your internal mutable objects when necessary to avoid returning the originals in your methods. 54

SPL/2010 How to create immutable objects? ● Immutable instance variables are always initialized during construction. 55

SPL/2010 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 java.lang.StringBuffer is updatable. 56

SPL/2010 Immutable objects are possibly applicable when: ● benefit of safe object outweighs cost of copying object each time it changes ● 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) 57

SPL/2010 helper class 58

SPL/2010 Stateless methods ● Another aspect of immutability are stateless methods. ● A stateless method is a method that does not change the object state. ● provide services 59

SPL/2010 Publish and Escape: behavior and implementation of classes Publish ● internal state of an object is published if it is accessible from outside – public member. By definition, this member is published as soon as the object is created. – private member to which a reference is returned by a public method call get() ● published members must be protected – immutable – locks 60

SPL/2010 Publish and Escape: behavior and implementation of classes ● Escape ● internal state of object has escaped if reference to internal state is available outside – Example: returning a reference to an internal member of an immutable object ● avoid 'this' to escape during construction – other objects could access the object before it has reached a valid state 61

SPL/2010 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. 62

SPL/2010 Example 1: Observer design pattern ● Object registers itself to some event source to be notified each time something happens ● Example: a vector can notify each time a modification happens (element added/removed). 63

SPL/2010 EventListenerImpl : object who would like to be notified on events of the EventSource 64

SPL/2010 Explicit escape ● '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 65

SPL/

SPL/2010 Implicit escape ● In example 2 'this' escaped implicitly. ● A reference to the object under construction is being published ● When creating InnerListener it received 'this' of EventListenerImpl2 ● how would it be able to call the eventReceived method? 67