1 / 24

Operating Systems CMPSC 473

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

tabithah
Télécharger la présentation

Operating Systems CMPSC 473

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating SystemsCMPSC 473 Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar

  2. Mid-semester feedback • On Angel, format similar to SRTEs • Please submit by end of the week

  3. Agenda • Last class • Condition variables • Semaphores • Next: More on condition variables and semaphores

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

  5. 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!

  6. 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); }

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

  8. 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?

  9. 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); } }

  10. 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?

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

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

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

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

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

  16. Compare locks, CVs, semaphores • Ease of use • Busy wait • Generally, CVs/semaphores better • Locks good for small critical sections on multi-processors • Signaling capabilities

  17. Classical Problems of Synchronization • Bounded-Buffer Problem • Readers and Writers Problem • Dining-Philosophers Problem

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

  19. 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); }

  20. 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 }

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

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

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

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

More Related