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

▶

Dec 30, 2022 180 likes •267 views

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.

SLIDE 1

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

SLIDE 2

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

EXCH r a =    tempReg := r r := Mem(a) Mem(a) := tempReg   

Executed atomically “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

SLIDE 3

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

SLIDE 4

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

SLIDE 5

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

SLIDE 6

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

SLIDE 7

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)

r turn = i

end loop release: r(i) := false 7

SLIDE 8

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

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