SPL/2010 Liveness And Performance 1

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

SPL/2010 Performance ● Latency - How quickly can your program respond to events? 3

SPL/2010 Performance ● Efficiency - What is the computational complexity of your program? How efficiently are you using the RTEs resources? 4

SPL/2010 Throughput vs. Latency ● Example: ● Spl AirLines -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 5

SPL/2010 Liveness ● "Something useful eventually happens within an activity" 6

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

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

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

SPL/

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

SPL/2010 DeadLock ● deadlock = two or more competing actions are waiting for each other to finish in a circular chain ● neither ever does 12

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

SPL/2010 Deadlock 14

SPL/2010 Deadlock 15

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

SPL/

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

SPL/

SPL/2010 Deadlock ● Thread 1 ● acquire lock for a on entering a.swapValue(b) ● execute t=getValue() success fully (since already held) ● block waiting for lock of b on entering v= other.getValue() 20 ● Thread 2 ● acquire lock for b on entering b.swapValue (a) ● execute t=getValue() succes sfully (since already held) ● block waiting for lock of a on entering v = other.getValue()

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

SPL/

SPL/2010 Deadlock caused by wait ● Capacity queue 23

SPL/

SPL/2010 Dining Philosophers Problem 25

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

SPL/

SPL/

SPL/

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

SPL/

SPL/2010 Deadlock Prevention ● Break symmetry - make sure one Philosopher grabs the right fork first. 32

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

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

SPL/2010 Resource Ordering: grab biggest 35

SPL/2010 Proof: no circular waits ● Given n philosophers 0,…,n-1, denote l i,r i left and right forks of philosopher n i (note l i =r i+1 (CW)) ● Assume a circular wait(CW/CCW) - assume CW ● 0 waits for fork 1 holds, 1 waits for fork 2 holds, …, n-1 wait2 for fork 0 holds ● 0 is waiting for l 0 =r 1, 1 is waiting for l 1 =r 2, …., n- 1 is waiting for l n-1 =r 0. 36

SPL/2010 Proof: no circular waits ● philosophers first grabs the bigger fork, thus r i >l i, as each philosopher holds its right fork,. ● Using the l i =r i+1 we get that, for n-1: l n-1 =r 0 that r 0 > r 0 – Since: r 0 >l 0 =r 1 >l 1 =r 2 >l 2 …r n-1 >l n-1 =r 0 37

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

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

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

SPL/2010 dining philosophers with no starvation 41

SPL/

SPL/