Liveness And Performance SPL2010 1 Performance Throughput How

Liveness And Performance SPL/2010 1

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

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

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

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

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

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

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

Live. Lock ● ● 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 SPL/2010 9

SPL/2010 10

● ● ● Runtime diagram wait()/notify. All() force threads to work one after the other Each time, the threads "undo" the work done by the other one. SPL/2010 11

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

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

Deadlock SPL/2010 14

Deadlock SPL/2010 15

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

SPL/2010 17

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

SPL/2010 19

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

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

SPL/2010 22

Deadlock caused by wait ● Capacity queue SPL/2010 23

SPL/2010 24

Dining Philosophers Problem SPL/2010 25

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

SPL/2010 27

SPL/2010 28

SPL/2010 29

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

SPL/2010 31

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

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

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 bookkeeping, or careful implementation. SPL/2010 34

Resource Ordering: grab biggest SPL/2010 35

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

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=r 0 that r 0> r 0 – Since: r 0>l 0=r 1>l 1=r 2>l 2…rn-1>ln-1=r 0 SPL/2010 37

Starvation ● dining philosophers. ● grab the bigger fork first policy ● t 1 is faster that t 2 ● Ponder ● Eat ● t 2 rarely (if at all) succeeds in grabbing the fork shared with t 1. t 2 Starving. SPL/2010 38

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

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

dining philosophers with no starvation SPL/2010 41

SPL/2010 42

SPL/2010 43