1 / 23

Monitors: An Operating System Structuring Concept

Monitors: An Operating System Structuring Concept. Paper by: C. A. R. Hoare Presented by: Sabrina Brick. Why monitors?. Concurrency has always been an OS issue Resource allocation is necessary among competing processes Timer interrupts

parson
Download Presentation

Monitors: An Operating System Structuring Concept

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. Monitors: An Operating System Structuring Concept Paper by: C. A. R. Hoare Presented by: Sabrina Brick

  2. Why monitors? • Concurrency has always been an OS issue • Resource allocation is necessary among competing processes • Timer interrupts • Existing synchronization mechanisms (semaphores, locks) are subject to hard-to-find, subtle bugs.

  3. What is a monitor? • A collection of data and procedures • Mutual exclusion • allows controlled acquisition and release of critical resources • single anonymous lock automatically acquired and released at entry and exit • Data encapsulation • monitor procedures are “entry points” for accessing data

  4. Monitors: a language construct • Monitors are a programming language construct • anonymous lock issues handled by compiler and OS • detection of invalid accesses to critical sections happens at compile time • process of detection can be automated by compiler by scanning the text of the program

  5. An Abstract Monitor name: monitor …local declarations …initialize local data proc1 (…parameters) …statement list proc2 (…parameters) …statement list proc3 (…parameters) …statement list

  6. Rules to Follow with Monitors • Any process can call a monitor procedure at any time • But only one process can be inside a monitor at any time (mutual exclusion) • No process can directly access a monitor’s local variables (data encapsulation) • A monitor may only access its local variables • Why? Race conditions could occur! “Chaos will ensue”!

  7. Enforcing the Rules • “wait” operation • current process is put to sleep • “signal” operation • wakes up a sleeping process • condition variables • May have different reasons for “waiting” or “signaling” • Processes waiting on a particular condition enter its queue

  8. car: monitor occupied: Boolean; occupied := false; nonOccupied: condition; procedure enterCar() if occupied then nonOccupied.wait; occupied = true; procedure exitCar() occupied = false; nonOccupied.signal; What possible problem exists? monitor declaration local variables / initializations procedure procedure Sabrina’s Car: a running example

  9. The Possible Problem • As discussed in Birrell’s paper (last class): • First process: • Completes it’s work with critical section • Signals a process waiting on “nonOccupied” • Starts to release the monitor when… • Second process: • Is awakened by first process • Tries an “entry point” into the monitor • First process isn’t finished releasing it so it blocks again! • This can’t happen with Hoare’s approach: • Signal must be the last operation in a monitor. • Signal and monitor exit are a combined operation.

  10. Multiple Conditions • Sometimes it is necessary to be able to wait on multiple things • Can be implemented with multiple conditions • Example: 2 reasons to enter car • drive (empties tank) • fill up car • Two reasons to wait: • Going to gas station but tank is already full • Going to drive but tank is (almost) empty

  11. Sabrina’s Car: a running example car: monitor emptyTank, fullTank: condition; tank: stack; tank := stack of 10 gallons; //10 gallon tank //filled in increments of a gallon procedure driveCar() if tank.isAlmostEmpty then fullTank.wait; tank.pop(); //consume gas in increments of a gallon emptyTank.signal; procedure fillCar() if tank.isFull then emptyTank.wait; tank.push(gallons.pop); //assume gas station “stack” has infinite supply fullTank.signal;

  12. Condition Queue • Might want to check if any process is waiting on a condition • The “condition queue” returns true if a process is waiting on a condition • Example: filling the tank only if someone is waiting to drive the car.

  13. Sabrina’s Car: a running example car: monitor emtpyTank, fullTank: condition; tank: stack; tank := stack of 10 gallons; //10 gallon tank //filled in increments of a gallon procedure driveCar() if tank.isAlmostEmpty then fullTank.wait; tank.pop(); //consume gas in increments of a gallon emptyTank.signal; procedure fillCar() if tank.isFull then emptyTank.wait; if fullTank.queue //returns true if a process is waiting on fullTank tank.push(gallons.pop); //assume gas station “stack” has infinite supply fullTank.signal;

  14. Priority: Scheduled Waits • A waiting process is given a number • The process with the lowest number gets woken up first • Example: People who want to drive my car are prioritized: • Highest: Me! • Medium: Family • Lowest: Friends/Others

  15. Sabrina’s Car: a running example car: monitor emtpyTank, fullTank: condition; tank: stack; tank := stack of 10 gallons; //10 gallon tank //filled in increments of a gallon procedure driveCar(p: person) if tank.isAlmostEmpty then if p.isSabrina then fullTank.wait(1); if p.isFamily then fullTank.wait(2); if p.isFriendorOther then fullTank.wait(3); tank.pop(); //consume gas in increments of a gallon emptyTank.signal; procedure fillCar() if tank.isFull then emptyTank.wait; if fullTank.queue tank.push(gallons.pop); //assume gas station has infinite supply fullTank.signal;

  16. Other issues • Power of Monitors • Monitor->semaphore and vice versa • Proof rules • I {b.wait} I&B • I&B {b.signal} I I : the invariant B : the condition that a process waiting on b wants to be true before its woken up b : the condition variable

  17. Lots of Great Examples • OS Examples: • Bounded Buffer • Alarm clock • Disk head scheduler • Reader/writer • Buffer Allocation

  18. Monitors and Granularity • Monitors are designed for course-grained locking • Example: locking an entire data structure rather than its individual components. • Is this an appropriate solution for all cases? • Why or why not? • What problems arise when the granularity is too coarse? What about the opposite case?

  19. Disabling Interrupts car: monitor occupied: Boolean; occupied := false; nonOccupied: condition; procedure enterCar() //disableInterrupts(); if occupied then nonOccupied.wait; occupied = true; //enableInterrupts(); procedure exitCar() //disableInterrupts(); occupied = false; nonOccupied.signal; //enableInterrupts(); “Yellow code” inserted into binary by compiler Which is the better approach? Why? Using a lock car: monitor occupied: Boolean; occupied := false; nonOccupied: condition; //lock1: lock; procedure enterCar() //lock1.acquire(); if occupied then nonOccupied.wait; occupied = true; //lock1.release(); procedure exitCar() //lock1.acquire(); occupied = false; nonOccupied.signal; //lock1.release(); //lock1.acquire() //disableInterrupts(); //lockVar = 1; //enableInterrupts(); Monitors: implementation issues

  20. What problems do monitors solve? • Mutual exclusion • Encapsulation of data • Compiler can automatically scan program text for some types of synchronization bugs • Synchronization of shared data access simplified vs. semaphores and locks • Good for problems that require course granularity • Invariants are guaranteed after waits • Theoretically, a process that waits on a condition doesn’t have to retest the condition when it is awakened.

  21. What remains problematic? • No way to check dynamically allocated shared data • Signals are as error prone as with other synchronization mechanisms • Deadlock can still happen in monitor code • Programmer can still screw up • Monitors are available in very few languages

  22. Conclusions • Monitors are a synchronization mechanism • A higher level, easier to use abstraction, better encapsulation than semaphores, etc. • Monitors still suffer from various problems • Let’s take a look at working model that addresses some of those issues! (Suzanne’s presentation)

  23. References • Jon Walpole • “Monitors: An Operating Systems Structuring Concept” Hoare. • Modern Operating Systems, Second Edition. Tannenbaum, pp. 115-119. • Emerson Murphy-Hill presentation from CS533, Winter 2005 • http://en.wikipedia.org/wiki/C._A._R._Hoare

More Related