Implementing Mutual Exclusion We assume that each thread, i , is of - PDF document

Concurrent programming slides T.S. Norvell (c) 2001 Implementing Mutual Exclusion We assume that each thread, i , is of the form loop non critical stuff acquire( i ) critical section release( i ) end loop Requirements: • Mutual exclusion. At most one thread may be in its critical section at a time • No starvation. Assuming no thread in Þ nitely loops in its critical section, each thread that tries to enter will eventually enter its critical section Level 0 Turn off interrupts acquire( i ) : Disable the interrupts release( i ) : Enable interrupts Pro: 1

Concurrent programming slides T.S. Norvell (c) 2001 • Fast Con: • Doesn’t work on multiprocessors • Interrupt processing is delayed, so critical section must be very short. • Only supports one class of critical section Level 1 Busy waiting protocols Hardware based busy waiting protocols Example: Some computers have an exchange instruction    tempReg := r  Executed r := Mem ( a ) EXCH r a = atomically   Mem ( a ) := tempReg “Executed atomically” means that the fetch and store are executed as one action on the memory. No other processor may insert a store between the fetch and the store. Now we can build a mutual exclusion algorithm Global data and initialization: var lock := false 2

Concurrent programming slides T.S. Norvell (c) 2001 acquire(i): var register key := true loop % Busy wait loop Exch key lock exit when not key end loop release(i): lock := false If the hardware lacks an exchange instruction (or similar), then we can build one (for a uniprocessor) MOVE r TO R0 DISABLE ; FETCH a TO r ; STORE R0 TO a ; ENABLE Note: Other special instructions can also be used. E.g. test-and-set. All require a pair of memory accesses to be atomic. 3

Concurrent programming slides T.S. Norvell (c) 2001 Pro • Can be used for multiple classes of critical section (using multiple locks) • Works for shared memory multiprocessors (assuming the memory system supports the special instruction) • Works for any number of threads Con • Busy waiting is a poor use of the CPU (poor utilization) • Requires fair scheduling. Why? Consider this scenario ∗ Thread 13 with low priority acquires a lock ∗ Thread 26 with high priority enters busy loop ∗ If the scheduler consistently schedules thread 26 rather than thread 13, then neither will ever advance 4

Concurrent programming slides T.S. Norvell (c) 2001 Safe-sluice: A ß awed purely-software solution. We assume there are only two threads per class of critical section For two processes: i ∈ { 0 , 1 } Global data and initialization: var r : array 0..1 of boolean := init ( false , false ) acquire(i): % For thread i r( i ) := true loop exit when not r( 1 − i ) end loop release(i): r( i ) := false 5

Concurrent programming slides T.S. Norvell (c) 2001 The problem with the safe sluice: If both threads enter acquire at the same time, they can deadlock. r(0) := true r(1) := true Now neither thread can exit its busy wait loop. The solution is to give one thread priority. The turn variable is either 0 or 1. Thread turn has priority. This leads to “Peterson’s algorithm” 6

Concurrent programming slides T.S. Norvell (c) 2001 Peterson’s algorithm: A purely software solution We assume there are only two threads per class of critical section. For two processes: i ∈ { 0 , 1 } : Global data and initialization: var r : array 0..1 of boolean := init ( false , false ) var turn : 0..1 := 0 acquire(i): % For thread i r( i ) := true turn := 1 − i loop exit when not r( 1 − i ) or turn = i end loop release: r( i ) := false 7

Concurrent programming slides T.S. Norvell (c) 2001 Note that if we interchange the Þ rst two statements of acquire, the protocol no longer works. We can prove Peterson’s algorithm (mutual exclusion, freedom from deadlock) in a couple of ways • Human reasoning, expressed as a mathematical proof • Statespace exploration. We can show that any state where both threads are in their critical section is unreachable from the initial state. We can generalize from 2 threads to any Þ xed number of threads by arranging the threads in a single knockout tournament structure. Other software solutions also exist (e.g., the bakery algorithm) Pro • Works on a multiprocessor with no need for hardware support (beyond a certain level of cache consistency) • Works for multiple classes of critical section Con • Busy waiting is a poor use of the CPU (poor utilization) • Requires fair scheduling. 8