1. Liveness And Performance
Lecture 10 
Liveness And Performance

2. Performance
Latency - the time required to perform some action or to produce some result.
Measured in some time-units.
Example: It takes four hours to assemble a car.

3. Performance
Throughput -is the number of actions executed or produced per unit of time.
Measured in units of whatever is being produced per unit of time.
Examples:
The factory assembles 1000 cars a day.
HTTP web server - how many pages per second can the server actually serve?
memory bandwidth: MBs/sec.

4. Performance Efficiency –
What is the computational complexity of your program?
How efficiently are you using the RTEs resources?
Related to both latency and throughput.

5. Liveness "Something useful eventually happens within an activity“
We have seen several cases where a program stops:
Acquiring locks.
Waiting on Objects.
Waiting for I/O.
Waiting for CPU time.
Failures.
Resource exhaustion.

6. LiveLock narrow hallway - one person may pass at time
Alice started walking down the hallway
Bob is approaching her from the other side.
Alice decides to let Bob pass her by moving left.
Bob, at the same time, decides to let Alice pass him by moving right

7. LiveLock
narrow hallway - one person may pass at time
Alice started walking down the hallway
Bob is approaching her from the other side.
Alice decides to let Bob pass her by moving left.
Bob, at the same time, decides to let Alice pass him by moving right
Both move to same side - still in each-other's way!
Alice moves to her right
Bob, at the same time, moves to his left.
Alice and Bob are doing something, but there is no global progress!

8. LiveLock
Livelock = two threads canceling each others' actions.
due to bad design - re-design system

10. Runtime diagram
wait()/notifyAll() force threads to work one after the other.
Each time, the threads "undo" the work done by the other one.

11. DeadLock
Deadlock =  two or more competing actions are waiting for each other to finish in a circular chain
neither ever does

12. Deadlock

13. Deadlock – erasing board
two people erase one board, with one eraser
If person A takes board and B takes the eraser, a deadlock occurs.
To finish erasing board
A needs the eraser
B needs the board

14. A first tries to grab board. If succeeds, he tries to grab the eraser.
 Taking algorithm:
A first tries to grab board. If succeeds, he tries to grab the eraser.
B does the same, but in the opposite order.
"grab" = locking the appropriate object

16. Thread.yield()
notify the system that the current thread is willing to "give up the CPU" for a while
scheduler selects different thread to run

18. Deadlock Thread 1 Thread 2
acquire lock for a on entering a.swapValue(b)
execute t=getValue() successfully (since already held)
block waiting for lock of b on entering v= other.getValue()
Thread 2
acquire lock for b on entering  b.swapValue (a)
execute t=getValue() successfully (since already held)
block waiting for lock of a on entering v = other.getValue()

19. Deadlock – circular dependency

20. Deadlock caused by circular lock
Both threads are blocked due to circular wait
Resource ordering solution:
grab locks in the same order to avoid deadlocks

22. Deadlock caused by wait

24. Dining Philosophers Problem

25. Dining Philosophers Problem
N philosophers (=threads) in a circle, each with a plate of in front of him.
N forks (=resources) - between any two philosophers there is exactly one fork
Philosophers ponder and eat (=methods)
To eat, a philosopher must grab both forks to his left and right (=locks).
He then eats and returns forks to table

30. running the code with 3 Confuciuses:
0 is pondering
1 is pondering
2 is pondering
0 is hungry
1 is hungry
2 is hungry
deadlock: each grabbed his left fork, and will wait forever for his right fork

31. Deadlock Prevention
Solution 1: Break symmetry/cycle make sure one Philosopher grabs the right fork first.
Solution 2: Resource ordering make sure forks are grabbed in some global order (rather than left and right of each philosopher).

32. Deadlock Prevention
Solution 3: Request all resources atomically each thread asks for ALL resources atomically.
adding another lock known to all philosophers, which they must grab before trying to grab any fork and release once they have grabbed both forks.
not recommended - requires another lock, managed by the programmer, requires book-keeping, or careful implementation.

33. Resource Ordering: make two philosophers grab the same fork FIRST.

34. Starvation dining philosophers. No Circular dependency.
“t1 is faster that t2”
Ponder
Eat
t2 rarely (if at all) succeeds in grabbing the fork shared with t1. t2 Starving.

35. Starvation
Several threads all waiting for a shared resource, which is repeatedly available.
At least one thread never (or rarely) gets its hands on the shared resource.
Identifying starvation is hard
Solving starvation is done at design time.

36. Starvation solution
Use synchronization primitives which support ordering.
synchronized construct does not guarantee ordering of blocked threads
Semaphore class supports ordering.
Fairness flag in C’tor. 

37. Semaphore fairness
First-In-First-Out (FIFO): thread that has been waiting the longest is always selected.

38. dining philosophers with no starvation