13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Mechanisms 275enter through the entry queue, where they are blocked until the guard procedures are freeof any activity. Entrance 2 is unlocked only if there is no activity in the main room.Door 1 is always unlocked; when it is opened to let an activity out, door 2 is unlocked.It is not hard to implement this kind of monitor using only semaphores. A compilercould translate guard procedures into the following code:Down(MonitorEmpty);guard procedure bodyUp(MonitorEmpty);The fact that the programmer does not need to remember the final Up operation makesmonitors easier and safer to use than bare semaphores. The fact that all the code that canaffect the shared variables is packaged in one place also makes it easier to check that thevariables are properly used.It is not hard to find situations in which the simple monitors we have shown so farare insufficient. As it stands, they have no facility for synchronization. The producersconsumersproblem is a good example of a situation where both mutual exclusion andsynchronization are needed.Producers-consumers problem<strong>An</strong>y number of producer activities and consumer activities are running. At anytime, a producer activity may create some data. At any time, a consumer activitymay want to accept some data. The data should be saved in a buffer untilthey are needed. Since the buffer is finite, we want a producer to block if itsnew creation would overflow the buffer. We also want a consumer to block ifthere are no data available when it wants them. Data should be accepted in theorder in which they are produced, although we relax this rule somewhat fordata produced or consumed simultaneously.We can use a monitor to implement a bounded buffer shared among all producers andconsumers. The data-abstraction features of the monitor will collect the BufferPut andBufferGet operations in one place, so the program is easy to debug and maintain. Themutual-exclusion properties of the monitor will ensure that two producers don’t attemptto modify the buffer at the same time and, more generally, that simultaneous conflictinguses are prevented. Synchronization features will be used to block producers and consumerswhen the buffer is full or empty.Here is a monitor implementation of bounded buffers:1 monitor BoundedBuffer;23 export GetBuffer, PutBuffer;45 const6 Size = 10; { number of elements in the buffer at one time }7 type8 Datum = ... { the data type of the contents of the buffer }9 var10 Buffer : array 0:Size-1 of Datum;11 Count : 0..Size; { how many elements currently in the buffer }12 NextIn, NextOut : 0..Size-1;13 { index of next datum to place in the buffer or remove }14 NonEmpty, NonFull : condition;15

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!