Liveness And Performance

1. Liveness And Performance

2. Performance • Throughput- How much work can your program complete in a given time unit? • Example: HTTP web server - how many pages per second can the server actually serve.

3. Performance • Latency - How quickly can your program respond to events?

4. Performance • Efficiency - What is the computational complexity of your program? How efficiently are you using the RTEs resources?

5. Throughput vs. Latency • Example: • SplAirLines -Tel-Aviv - New York. • two airplanes per day from TA to NY. • airplane holds 250 passengers. • throughput of TA-NY is 500 passengers per day. • latency of flight is the time interval TA-NY

6. Liveness • "Something useful eventually happens within an activity"

7. Liveness • When can the progress of our program be stopped? Up to now we have seen several cases • Acquiring locks. • Waiting on Objects. • Waiting for I/O. • Waiting for CPU time. • Failures. • Resource exhaustion.

8. 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 of hallway - still in each-other's way! • Alice moves to her right • Bob, at the same time, moves to his left.

9. LiveLock • Alice and Bob are doing something,, but there is no global progress! • Livelock = two threads canceling each others' actions, • due to bad design - re-design system

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

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

13. Deadlock • Example: • two people erase one board, with one eraser • If person A takes board and B takes the eraser, a deadlock occurs. • To finish drawing a diagram • A needs the eraser • B needs the board

14. Deadlock

15. Deadlock

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

18. Thread.yield • notify the system that the current thread is willing to "give up the CPU" for a while • schedulerselects different thread to run

20. Deadlock • Thread 1 • acquire lock for a on entering a.swapValue(b) • executet=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()

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

23. Deadlock caused by wait • Capacity queue

25. Dining Philosophers Problem

26. Dining Philosophers Problem • N philosophers (=threads) in a circle, each with a plate of in front of him. • N forks, such that between any two philosophers there is exactly one fork • Philosophers ponder and eat • To eat, a philosopher must grab both forks to his left and right. • 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

32. Deadlock Prevention • Break symmetry - make sure one Philosopher grabs the right fork first.

33. Deadlock Prevention • Resource ordering - make sure forks are grabbed in some global order (rather than left and right of each philosopher).

34. Deadlock Prevention • Request all resources atomically - each thread asks for all its needed resources atomically. • adding another lock (semaphore initiated to 1) 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.

35. Resource Ordering: grab biggest

36. Proof: no circular waits • Given n philosophers 0,…,n-1, denote li,rileft and right forks of philosopher ni(note li=ri+1 (CW)) • Assume a circular wait(CW/CCW) - assume CW • 0waits for fork1holds,1waits for fork2holds, …, n-1wait2 for fork0holds • 0 is waiting for l0=r1 , 1 is waiting for  l1=r2, …., n-1 is waiting for  ln-1=r0.

37. Proof: no circular waits • philosophers first grabs the bigger fork, thus ri>li, as each philosopher holds its right fork, . • Using the li=ri+1   we get that, for n-1: ln-1=r0 that r0>r0 • Since: r0>l0=r1>l1=r2>l2…rn-1>ln-1=r0

38. Starvation • dining philosophers. • grab the bigger fork first policy • t1 is faster that t2 • Ponder • Eat • t2 rarely (if at all) succeeds in grabbing the fork shared with t1. t2 Starving.

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

40. Starvation solution • synchronization primitives which support ordering. • synchronized construct does not guarantee ordering on blocked threads (wait-notify) • Semaphore class supports ordering. • fairness. 

41. dining philosophers with no starvation