safety
DESCRIPTION
Safety. system designing for concurrent execution environments. s ystem: 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 - PowerPoint PPT PresentationTRANSCRIPT
SPL/2010SPL/2010
Safety
1
SPL/2010SPL/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
completes2
SPL/2010SPL/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/2010SPL/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/2010SPL/2010
language constructs for generic code
5
SPL/2010SPL/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/2010SPL/2010
Generics
● generics - extra argument for standard containers ● express programmer intention ● can be used in any class ● type-safety
7
SPL/2010SPL/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/2010SPL/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/2010SPL/2010
Multi-Threaded Safety
10
SPL/2010SPL/2010
safety preservation: ensuring objects are in consistent states
concurrency control: disabling of access due to actions by other threads.
11
SPL/2010SPL/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/2010SPL/2010 13
SPL/2010SPL/2010
class Even
● consistency of class state: ● even counter at all times● operation: increment counter
14
SPL/2010SPL/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/2010SPL/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/2010SPL/2010 17
SPL/2010SPL/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/2010SPL/2010
system = collection of interconnected objects
● structured collection
19
SPL/2010SPL/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/2010SPL/2010
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.
21
SPL/2010SPL/2010
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) holds22
SPL/2010SPL/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 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 part23
SPL/2010SPL/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 sure the @inv, @pre and @post hold
● in the hybrid execution model?
24
SPL/2010SPL/2010 25
SPL/2010SPL/2010
● 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
SPL/2010SPL/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/2010SPL/2010
Investigation
● add() - performs many more actions than you can see…
28
SPL/2010SPL/2010
Investigation
● pseudo JVM code:
● execution of any thread may be interrupted at any line…
29
SPL/2010SPL/2010
Investigation
30
SPL/2010SPL/2010
● After the first thread finishes first add(), counter_ = 2
● After the second thread finishes the first add(), counter_ = 5
31
SPL/2010SPL/2010
Reapair?
●
@pre, @post and @inv hold32
SPL/2010SPL/2010
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)
33
SPL/2010SPL/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 (@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
SPL/2010SPL/2010
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
SPL/2010SPL/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+=836
SPL/2010SPL/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/2010SPL/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/2010SPL/2010
example: abstract computation system
Sequences transitions from object perspective:
● O1: S11 --m1--> S12 --m2--> S13● O2: S21 --n1--> S22
39
SPL/2010SPL/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 S1340
SPL/2010SPL/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/2010SPL/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/2010SPL/2010
● safety in concurrent RTEs: ● reduce scheduling of primitive state
transitions among passive objects – serialization constraints among independent
transitions
43
SPL/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/2010
● immutable object - object whose state cannot be modified after it is created.
● mutable object - can be modified after it is created
48
SPL/2010SPL/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/2010SPL/2010
Factory:
50
SPL/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/2010
How to create immutable objects?
● Immutable instance variables are always initialized during construction.
55
SPL/2010SPL/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/2010SPL/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/2010SPL/2010
helper class
58
SPL/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/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/2010SPL/2010
EventListenerImpl : object who would like to be notified on events of the EventSource
64
SPL/2010SPL/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/2010SPL/2010 66
SPL/2010SPL/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