240 likes | 264 Views
Operating Systems CMPSC 473. Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar. Mid-semester feedback. On Angel, format similar to SRTEs Please submit by end of the week. Agenda. Last class Condition variables Semaphores
E N D
Operating SystemsCMPSC 473 Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar
Mid-semester feedback • On Angel, format similar to SRTEs • Please submit by end of the week
Agenda • Last class • Condition variables • Semaphores • Next: More on condition variables and semaphores
Issues/Questions from Last Class • Improving concurrency of producer/consumer solution using condition variables • Atomicity of wait() for semaphores • # inteleavings for concurrent code with synchronization constraints
cond_t not_full, not_empty; mutex_lock m; int count == 0; Produce() { mutex_lock (m); if (count == N) wait (not_full,m); … ADD TO BUFFER, count++ … signal (not_empty); mutex_unlock (m); } Consume() { mutex_lock (m); if (count == 0) wait (not_empty,m); … REMOVE FROM BUFFER, count-- … signal (not_full); mutex_unlock (m); } NOTE: You can improve this code for more concurrency!
cond_t not_full, not_empty; mutex_lock m; int count == 0; Produce() { mutex_lock (m); if (count == N) wait (not_full,m); count++; find pos to add // pos local variable mutex_unlock (m); … ADD TO BUFFER at pos … signal (not_empty); } Consume() { mutex_lock (m); if (count == 0) wait (not_empty,m); count--; find pos to remove from // pos local variable mutex_unlock (m); … REMOVE FROM BUFFER at pos … signal (not_full); }
Semaphore Implementation: Atomicity • With busy wait • Entire wait (S) must be atomic • Note: Error in last class slide which said only S-- needed to be atomic! • How? • Disable interrupts • Or use another mutex solution, e.g., lock
Semaphore Implementation with no Busy waiting • With each semaphore there is an associated waiting queue. A waiting queue has two data items: • value (of type integer) • pointer to a list of PCBs • Introduce a pointer in the PCB structure • Two operations: • block – place the process invoking the operation on the appropriate waiting queue. • wakeup – remove one of processes in the waiting queue and place it in the ready queue. • FIFO ordering => bounded-waiting Is busy waiting completely gone?
Semaphore Implementation with no Busy waiting (Cont.) • Implementation of wait: wait (S){ value--; if (value < 0) { add this process to waiting queue block(); } } • Implementation of signal: Signal (S){ value++; if (value <= 0) { remove a process P from the waiting queue wakeup(P); } }
Semaphore Implementation with no Busy waiting: Atomicity • Implementation of wait: wait (S){ value--; if (value < 0) { add this process to waiting queue block(); } } • Implementation of signal: Signal (S){ value++; if (value <= 0) { remove a process P from the waiting queue wakeup(P); } } How to make these atomic?
Semaphore Implementation with no Busy waiting: Atomicity • Uniprocessors • Disable interrupts during wait and signal • Once interrupts are disabled, instructions from different processes cannot be interleaved. Only the currently running process executes until interrupts are re-enabled and the scheduler can regain control. • Multi-processors • Inhibiting interrupts does not work • Instructions from different processes (running on different processors) may be interleaved in some arbitrary way • If the hardware does not provide any special instructions, we can employ any of the correct software solutions (e.g., Peterson’s, Bakery) for the critical-section problem, where the critical sections consist of the wait and signal operations (EXTREMELY COOL) • So, we have not completely eliminated busy waiting with this definition of wait and signal • We have moved busy waiting to the critical sections • Furthermore, we have limited busy waiting to the critical sections of wait and signal
Semaphore Implementation with no Busy waiting: Atomicity • Uniprocessors • Disable interrupts during wait and signal • Once interrupts are disabled, instructions from different processes cannot be interleaved. Only the currently running process executes until interrupts are re-enabled and the scheduler can regain control. • Multi-processors • Inhibiting interrupts does not work • Instructions from different processes (running on different processors) may be interleaved in some arbitrary way • If the hardware does not provide any special instructions, we can employ any of the correct software solutions (e.g., Peterson’s, Bakery) for the critical-section problem, where the critical sections consist of the wait and signal operations (EXTREMELY COOL) • So, we have not completely eliminated busy waiting with this definition of wait and signal • We have moved busy waiting to the critical sections • Furthermore, we have limited busy waiting to the critical sections of wait and signal
Semaphore Implementation with no Busy waiting: Atomicity • Uniprocessors • Disable interrupts during wait and signal • Once interrupts are disabled, instructions from different processes cannot be interleaved. Only the currently running process executes until interrupts are re-enabled and the scheduler can regain control. • Multi-processors • Inhibiting interrupts does not work • Instructions from different processes (running on different processors) may be interleaved in some arbitrary way • If the hardware does not provide any special instructions, we can employ any of the correct software solutions (e.g., Peterson’s) for the critical-section problem, where the critical sections consist of the wait and signal operations (EXTREMELY COOL) • So, we have not completely eliminated busy waiting with this definition of wait and signal • We have moved busy waiting to the critical sections • Furthermore, we have limited busy waiting to the critical sections of wait and signal
Semaphore Implementation with no Busy waiting: Atomicity • Uniprocessors • Disable interrupts during wait and signal • Once interrupts are disabled, instructions from different processes cannot be interleaved. Only the currently running process executes until interrupts are re-enabled and the scheduler can regain control. • Multi-processors • Inhibiting interrupts does not work • Instructions from different processes (running on different processors) may be interleaved in some arbitrary way • If the hardware does not provide any special instructions, we can employ any of the correct software solutions (e.g., Peterson’s) for the critical-section problem, where the critical sections consist of the wait and signal operations (EXTREMELY COOL) • So, we have not completely eliminated busy waiting with this definition of wait and signal • We have moved busy waiting to the critical sections • Furthermore, we have limited busy waiting to the critical sections of wait and signal
Sample incorrect use of semaphores • Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes • Let S and Q be two semaphores initialized to 1 P0P1 wait (S); wait (Q); wait (Q); wait (S); . . . signal (S); signal (Q); signal (Q); signal (S); • Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended.
Compare locks, CVs, semaphores • Ease of use • Busy wait • Generally, CVs/semaphores better • Locks good for small critical sections on multi-processors • Signaling capabilities
Classical Problems of Synchronization • Bounded-Buffer Problem • Readers and Writers Problem • Dining-Philosophers Problem
Bounded-Buffer Problem • N buffers, each can hold one item • Semaphore mutex initialized to the value 1 • Semaphore full initialized to the value 0 • Semaphore empty initialized to the value N
Bounded Buffer Problem (Cont.) • The structure of the producer process while (true) { // produce an item wait (empty); wait (mutex); // add the item to the buffer signal (mutex); signal (full); }
Bounded Buffer Problem (Cont.) • The structure of the consumer process while (true) { wait (full); wait (mutex); // remove an item from buffer signal (mutex); signal (empty); // consume the removed item }
Readers-Writers Problem A data set shared among a number of concurrent processes Readers – only read the data set; they do not perform any updates Writers – can both read and write Problem – allow multiple readers to read at the same time. Only one writer may access the shared data at a given time Shared Data Data set Semaphore mutex initialized to 1 Semaphore wrt initialized to 1 Integer readcount initialized to 0
Readers-Writers Problem (Cont.) The structure of a writer process do { wait (wrt) ; // writing is performed signal (wrt) ; } while (TRUE); • mutex = 1 • wrt = 1 • readcount = 0 Allow only one writer at a time to write
Readers-Writers Problem (Cont.) The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait (wrt) ; signal (mutex) // reading wait (mutex) ; readcount - - ; if (readcount == 0) signal (wrt) ; signal (mutex) ; } while (TRUE); • mutex = 1 • wrt = 1 • readcount = 0 Proceed only if no writer is writing; disallow writers once we proceed • Note 1: readcount • keeps track of the number of active readers • Note 2: Understand the • role of mutex (consider what • happens without it) Signal a writer only when there are no more active readers
Readers-Writers Problem (Cont.) The structure of a reader process do { wait (mutex) ; readcount ++ ; if (readcount == 1) wait (wrt) ; signal (mutex) // reading wait (mutex) ; readcount - - ; if (readcount == 0) signal (wrt) ; signal (mutex) ; } while (TRUE); • mutex = 1 • wrt = 1 • readcount = 0 Proceed only if no writer is writing; disallow writers once we proceed • Deadlock? • Starvation? Signal a writer only when there are no more active readers