Operating Systems CMPSC 473 Mutual Exclusion Lecture 13: October 12, 2010 Instructor: Bhuvan Urgaonkar.

Slides:



Advertisements
Similar presentations
1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
Advertisements

Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
Synchronization Principles Gordon College Stephen Brinton.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Enforcing Mutual Exclusion, Semaphores. Four different approaches Hardware support Disable interrupts Special instructions Software-defined approaches.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Objectives Understand.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Process Synchronization (Or The “Joys” of Concurrent.
02/23/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
What we will cover… Process Synchronization Basic Concepts
02/17/2010CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
1 School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 6: Process Synchronization Dr. Mohamed Hefeeda.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Module 6: Process Synchronization.
02/19/2007CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail,
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Background Concurrent.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
6.3 Peterson’s Solution The two processes share two variables: Int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Operating Systems CMPSC 473 Mutual Exclusion Lecture 14: October 14, 2010 Instructor: Bhuvan Urgaonkar.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization.
Operating Systems CSE 411 CPU Management Oct Lecture 14 Instructor: Bhuvan Urgaonkar.
1 Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Special Machine Instructions for Synchronization Semaphores.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Chap 6 Synchronization. Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms.
Chapter 6: Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Synchronization Background The Critical-Section.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
Chapter 6: Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Lecture 11: Synchronization (Chapter 6, cont)
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Module 6: Process Synchronization.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 22 Semaphores Classic.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Synchronization Background The Critical-Section Problem Peterson’s.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Deadlock and Starvation
Chapter 6: Process Synchronization
Process Synchronization
Process Synchronization: Semaphores
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
Deadlock and Starvation
Operating Systems CMPSC 473
Chapter 5: Process Synchronization
Chapter 6: Process Synchronization
Chapter 6: Process Synchronization
Chapter 5: Process Synchronization (Con’t)
Semaphore Originally called P() and V() wait (S) { while S <= 0
Process Synchronization
Lecture 2 Part 2 Process Synchronization
CSE 153 Design of Operating Systems Winter 2019
Process/Thread Synchronization (Part 2)
Presentation transcript:

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 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 P 0 P 1 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 Signal a writer only when there are no more active readers Note 1: readcount keeps track of the number of active readers Note 2: Understand the role of mutex (consider what happens without it)

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 Signal a writer only when there are no more active readers Deadlock? Starvation?