Liveness And Performance Lecture 10  Liveness And Performance

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.

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.

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

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.

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

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!

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

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

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

Deadlock

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

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

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

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

Deadlock – circular dependency

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

Deadlock caused by wait

Dining Philosophers Problem

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

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

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

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.

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

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.

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.

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. 

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

dining philosophers with no starvation