1. Lecture 8
Thread Safety

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

3. Safety Nothing bad should ever happen to an object:
Preserve objects’ consistency
Object remains consistent?
Formal definition of safety?
Type safety
Multi-threaded safety.

4. Multi-Threaded Safety
Type safety can be checked by compilers.
Multi-threaded safety – compilers can’t help.
Design classes carefully:
What are pre & post conditions and invariant of the class?
One practical difference between type safety and multithreaded safety is that most type-safety matters
can be checked automatically by compilers. A program that fails to pass compile-time checks cannot
even be run. Most multithreaded safety matters, however, cannot be checked automatically, and so
must rely on programmer discipline

5. class Even Implements a counter in even numbers:
0,2,4,6,8,10,….
Consistency of class state: 
Even counter at all times.
Operation: increment counter.

7. Pre/Post-conditions, Invariants
Invariant - object property regarding 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

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

9. You might ask yourself why do we need all of this "unnecessary" baggage, and you may be right in sequential execution. Indeed, in a sequential execution environment nothing wrong may happen to an Even object. However, in concurrent execution environments, things may fall apart

10. Stack interface example:

11. Stack interface example
The interface is not rich enough to define the pre/post and invariant conditions.
We can add two methods:
int count()
T itemAt(int i)

14. Consistency and computation
We introduced the pre/post and inv conditions to define: “an object is in consistent state”.
Only the object can update its own internal state.
Construction: after the constructor holds.

15. Consistency and computation
Each time a method is called: @pre condition should be checked.
After the method finishes computing: @post condition should be checked.
Naturally, a computation involves more than one object. The correctness condition for a system is that all object computations are correct - as viewed from the perspective of each object.

16. Consistency and computation
While a method is executing, there is no constraint that remains enforced.
Example: add()method in Even.

17. 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 concurrent execution model?

19. …Even class is not thread safe
run: 
…Even class is not thread safe

20. Investigation
At some point in each thread's execution, the thread is preempted by the environment in favor of another thread.
The preemption may take place any time during the execution of the thread.

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

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

23. Investigation Run: After this run: (before the print()) counter = 5!…
After this run: (before the print())
counter = 5!

24. Repair?
Unfortunately, a thread can be interrupted before line 3.

25. 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)

26. Interleaving of execution
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.

27. Global Criterion on Computation Correctness
The (finite) concurrent execution of a program is correct IFF:
Object @post.
Linearizability: at the end of computation:
Objects are in 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.
In general, there exist several definitions of what it means for a global distributed system to execute a program correctly

28. Understanding What Went Wrong
A computation which is correct in a sequential RTE, but incorrect in a concurrent RTE.
In concurrent RTE – we need extra-effort to ensure correctness.
Smallest steps of the computation are not single method execution.
They are instructions executed by the JVM, at the instruction set level.

29. Example: abstract computation system
Sequences transitions from object perspective:
O1: S11 --m1()--> S12 --m2()--> S13
O2: S21 --n1()--> S22
Now consider this example: an abstract computation system involves 2 objects O1 and O2. From the perspective of each object, the computation involves these sequences of transitions:

30. Example: abstract computation system
Sequential model RTE: 3 transitions ordered relative to each other into a single execution
If no dependency between executions: We can have 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

31. Dependency: n1() is called by O1 during the execution of m2()
O1: S11 --m1()--> S12 --m2()--> S13
O2: S21 --n1()--> S22
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
less possible total orderings in the sequential execution

32. Safety in concurrent RTEs:
Any mechanism that we will introduce will: Impose serialization constraints among independent transitions

33. Safe Concurrent Programming Ingredients
Immutability - avoiding state changes.
Eliminating the need for exclusion control by ensuring that methods never modify an object's state.
The object cannot enter inconsistent states!
one thread at a time can access object state, by protecting objects with
locks and related constructs.

34. Safe Concurrent Programming 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.
one thread at a time can access object state, by protecting objects with
locks and related constructs.

35. Safe Concurrent Programming Ingredients
Containment - Structurally 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.
one thread at a time can access object state, by protecting objects with
locks and related constructs.

36. Immutable Objects
immutable object  - object whose state cannot be modified after it is created.
mutable object - can be modified after it is created
If an object cannot change state - it can never encounter inconsistencies when multiple activities attempt to change its state!

37. Immutable Objects
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.

38. immutable Even
new object of Even - its internal state may not change - ever
object is always safe, even in concurrent execution environments.

39. Immutable Even class:
“Factory design”

40. Reminder:
Static methods  - use no instance variables of any object of the class they are defined in.
cannot access any instance variables.
ONLY static variables.

41. 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, or
make the constructor private and construct instances in factory methods.

42. Immutable objects are 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.

43. Immutable objects are 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).

44. Stateless methods
Another aspect of immutability are stateless methods.
A stateless method is a method that does not change the object state.
provide services

45. Adder using immutable Even

46. Immutable “Wrapper”

47. Immutable “Wrapper” Note that the previous example is weak.
The server inner fields can be modified even though it is final (either in relay or outside of it).
Only the reference field “server” cannot be modified.
Modifications:
Either server is created inside relay and is not exposed outside.
Relay only expose certain methods of server, that do not change the server’s state.

48. Publish and Escape: behavior and implementation of classes
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

49. Publish and Escape: behavior and implementation of classes
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

50. Example 1: Observer design pattern
Object registers itself to some listener object which will be notified each time something happens
Example: a vector can notify each time a modification happens (element added/removed).

51. EventListenerImpl : object who would like to be notified on events of the EventSource

52. 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

53. Possible fix? NO

54. 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?