SPL/2010SPL/2010

 Liveness And Performance

1

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

Performance● Latency - How quickly can your program

respond to events?

3

SPL/2010SPL/2010

Performance● Efficiency - What is the computational

complexity of your program? How efficiently are you using the RTEs resources?

4

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

Liveness● "Something useful eventually happens

within an activity"

6

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

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

DeadLock● deadlock =  two or more competing

actions are waiting for each other to finish in a circular chain● neither ever does

12

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

Deadlock

14

SPL/2010SPL/2010

Deadlock

15

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

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

SPL/2010SPL/2010

Deadlock● Thread 1● acquire lock for a on

entering a.swapValue(b)● execute t=getValue() succe

ssfully (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() succ

essfully (since already held)

● block waiting for lock of a on entering v = other.getValue()

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

SPL/2010SPL/2010

Deadlock caused by wait● Capacity queue

23

SPL/2010SPL/2010 24

SPL/2010SPL/2010

Dining Philosophers Problem

25

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

SPL/2010SPL/2010 28

SPL/2010SPL/2010 29

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

SPL/2010SPL/2010

Deadlock Prevention● Break symmetry - make sure one

Philosopher grabs the right fork first.

32

SPL/2010SPL/2010

Deadlock Prevention● Resource ordering - make sure forks

are grabbed in some global order (rather than left and right of each philosopher).

33

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

Resource Ordering: grab biggest

35

SPL/2010SPL/2010

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 for fork 1 holds, 1 waits for

fork 2 holds, …, n-1 wait2 for fork 0 holds● 0 is waiting for l0=r1 , 1 is waiting for  l1=r2,

…., n-1 is waiting for  ln-1=r0. 36

SPL/2010SPL/2010

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

37

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

dining philosophers with no starvation

41

SPL/2010SPL/2010 42

SPL/2010SPL/2010 43