More Synchronization, Semaphores Vivek Pai / Kai Li Princeton University.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Operating Systems Part III: Process Management (Process Synchronization)
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
EEE 435 Principles of Operating Systems Interprocess Communication Pt II (Modern Operating Systems 2.3)
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
Threads & Synchronization, Conclusion Vivek Pai Nov 20, 2001.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
Operating Systems ECE344 Ding Yuan Synchronization (I) -- Critical region and lock Lecture 5: Synchronization (I) -- Critical region and lock.
CS444/CS544 Operating Systems Synchronization 2/21/2006 Prof. Searleman
Enforcing Mutual Exclusion, Semaphores. Four different approaches Hardware support Disable interrupts Special instructions Software-defined approaches.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Semaphores. Announcements No CS 415 Section this Friday Tom Roeder will hold office hours Homework 2 is due today.
5.6.2 Thread Synchronization with Semaphores Semaphores can be used to notify other threads that events have occurred –Producer-consumer relationship Producer.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
Chapter 6: Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Principles Module 6: Synchronization 6.1 Background 6.2 The Critical-Section.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
Synchronization Solutions
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Semaphores. Readings r Silbershatz: Chapter 6 Mutual Exclusion in Critical Sections.
Semaphores and Bounded Buffer Andy Wang Operating Systems COP 4610 / CGS 5765.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Semaphores and Bounded Buffer. Semaphores  Semaphore is a type of generalized lock –Defined by Dijkstra in the last 60s –Main synchronization primitives.
Midterm 1 – Wednesday, June 4  Chapters 1-3: understand material as it relates to concepts covered  Chapter 4 - Processes: 4.1 Process Concept 4.2 Process.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
Kernel Locking Techniques by Robert Love presented by Scott Price.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
CSE 451: Operating Systems Winter 2012 Semaphores and Monitors Mark Zbikowski Gary Kimura.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CSE 153 Design of Operating Systems Winter 2015 Lecture 5: Synchronization.
Operating Systems COMP 4850/CISG 5550 Interprocess Communication, Part II Dr. James Money.
Synchronization CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Module 6: Process Synchronization.
Implementing Lock. From the Previous Lecture  The “too much milk” example shows that writing concurrent programs directly with load and store instructions.
CS 153 Design of Operating Systems Winter 2016 Lecture 7: Synchronization.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion Mutexes, Semaphores.
CS162 Section 2. True/False A thread needs to own a semaphore, meaning the thread has called semaphore.P(), before it can call semaphore.V() False: Any.
Homework 3-4 Sarah Diesburg Operating Systems COP 4610.
CS 311/350/550 Semaphores. Semaphores – General Idea Allows two or more concurrent threads to coordinate through signaling/waiting Has four main operations.
Interprocess Communication Race Conditions
CS703 - Advanced Operating Systems
CSE 120 Principles of Operating
Interprocess Communication (3)
Chapter 5: Process Synchronization
Lecture 13: Producer-Consumer and Semaphores
Sarah Diesburg Operating Systems COP 4610
Semaphores and Bounded Buffer
CSE 451: Operating Systems Winter Module 8 Semaphores and Monitors
Implementing Mutual Exclusion
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
Lecture 13: Producer-Consumer and Semaphores
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Chapter 6: Synchronization Tools
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
CSE 542: Operating Systems
Presentation transcript:

More Synchronization, Semaphores Vivek Pai / Kai Li Princeton University

2 Continuing on Synchronization So far, we’ve seen “Spinning” on lock during entire critical section Disabling interrupts for critical section (bad) Queue associated with each lock & blocking System calls for locking – possibly blocking Since system calls exist, is everything solved? Assume shared variable “count” Lock(&mutex); count++; Unlock(&mutex);

3 Cost of Protecting a Shared Variable Making lock system call Pushing parameter, sys call # onto stack Generating trap/interrupt to enter kernel System call in kernel Jump to appropriate function in kernel Verify process passed in valid pointer to mutex Do locking operation, block process if needed Actually change count – load/modify/store System call again to release mutex

4 What is Lock Contention? Competition for a lock Uncontended = rarely in use by someone else Contended = often used by someone else Held = currently in use by someone Question: what do these combinations do? Spinning on low-contention lock Spinning on high-contention lock Blocking on low-contention lock Blocking on high-contention lock

5 Things to Ponder If critical section is just “count++;”, what is the overhead of the synchronization Is there some other way of doing this? What if you don’t know how long the critical section will be?

6 What If You Have the Following Test-and-set – works at either user or kernel System calls for block/unblock Block takes some token and goes to sleep Unblock “wakes up” a waiter on token

7 User-Level Acquire/Release using Block and Unblock In what scenarios is this scheme appropriate? Where should it not be used? Acquire(lock) { while (!TAS(lock)) Block( lock ); } Release(lock) { lock = 0; Unblock( lock ); }

8 Semaphores (Dijkstra, 1965) Down or “P” Atomic Wait for semaphore to become positive and then decrement by 1 P(s) { if (--s < 0) Block(s); } V(s) { if (++s <= 0) Unblock(s); } Up or “V” –Atomic –Increment semaphore by 1 wake up a waiting P if any

9 Bounded Buffer (Consumer-Producer) Example: grep vivek access.log | more ProducerConsumer

10 Bounded Buffer w/ Semaphores mutex = 1 emptyCount = N; fullCount = 0; producer() { while (1) { produce an item P(emptyCount); P(mutex); put the item in buffer V(mutex); V(fullCount); } consumer() { while (1) { P(fullCount); P(mutex); take an item from buffer V(mutex); V(emptyCount); consume the item }

11 Implementing General Semaphores Need a mutex for each semaphore Block and Unblock need to release mutex after entering their critical section P(s) { Acquire(s.mutex); if (--s.value < 0) Block(s); else Release(s.mutex) } V(s) { Acquire(s.mutex); if (++s.value <= 0) Unblock(s); else Release(s.mutex) }

12 Implement General Semaphores with Acquire/Release Kotulski (1988) Two processes call P(s) (when s.value is 0) and preempted after Release(s.mutex) Two other processes call V(s) P(s) { Acquire(s.mutex); if (--s.value < 0) { Release(s.mutex); Acquire(s.delay); } else Release(s.mutex); } V(s) { Acquire(s.mutex); if (++s.value <= 0) Release(s.delay); Release(s.mutex); }

13 Hemmendinger’s Solution (1988) The idea is not to release s.mutex and turn it over individually to the waiting process P and V are executing in lockstep P(s) { Acquire(s.mutex); if (--s.value < 0) { Release(s.mutex); Acquire(s.delay); } Release(s.mutex); } V(s) { Acquire(s.mutex); if (++s.value <= 0) Release(s.delay); else Release(s.mutex); }

14 Kearns’s Solution (1988) P(s) { Acquire(s.mutex); if (--s.value < 0) { Release(s.mutex); Acquire(s.delay); Acquire(s.mutex); if (--s.wakecount > 0) Release(s.delay); } Release(s.mutex); } V(s) { Acquire(s.mutex); if (++s.value <= 0) { s.wakecount++; Release(s.delay); } Release(s.mutex); } Two Release( s.delay) calls are also possible

15 Hemmendinger’s Correction (1989) P(s) { Acquire(s.mutex); if (--s.value < 0) { Release(s.mutex); Acquire(s.delay); Acquire(s.mutex); if (--s.wakecount > 0) Release(s.delay); } Release(s.mutex); } V(s) { Acquire(s.mutex); if (++s.value <= 0) { s.wakecount++; if (s.wakecount == 1) Release(s.delay); } Release(s.mutex); } Correct but a complex solution

16 Hsieh’s Solution (1989) Use Acquire(s.delay) to block processes Correct but still a constrained implementation P(s) { Acquire(s.delay); Acquire(s.mutex); if (--s.value > 0) Release(s.delay); Release(s.mutex); } V(s) { Acquire(s.mutex); if (++s.value == 1) Release(s.delay); Release(s.mutex); }