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.

276 Concurrency Chapter 816 guard procedure PutBuffer(What : Datum);17 begin18 if Count = Size then19 wait NonFull;20 end;21 Buffer[NextIn] := What;22 NextIn := (NextIn + 1) mod Size;23 inc(Count);24 signal NonEmpty;25 end PutBuffer;2627 guard procedure GetBuffer(var Result : Datum);28 begin29 if Count = 0 then30 wait NonEmpty;31 end;32 Result := Buffer[NextOut];33 NextOut := (NextOut + 1) mod Size;34 dec(Count);35 signal NonFull;36 end GetBuffer;3738 begin { initialization }39 Count := 0;40 NextIn := 0;41 NextOut := 0;42 end BufferThis representation of bounded buffers satisfies our goals nicely. We need notworry that some other piece of program modifies the shared variables Buffer and Countbecause they are visible only within this monitor. There is no danger that several activitieswill try to modify Count simultaneously, will produce into the same cell of Buffersimultaneously, or will take data from the same cell of Buffer simultaneously, because allsuch behavior is restricted to guard procedures, which are mutually exclusive.Finally, we have provided a way for activities to be blocked if necessary. Themechanism is the new (predefined) type called condition. Both NonEmpty and NonFullare declared as conditions in line 14. Let us concentrate on the condition NonEmpty. Atline 30, a consumer that finds the buffer empty executes a wait on this condition. Thewait will block this activity until some other activity signals the condition. At that time,the blocked activity may continue. When it gets to line 32, it assumes that the buffer isno longer empty. <strong>An</strong>y producer that succeeds in placing new data in the buffer executesa signal on the NonEmpty condition at line 24. This operation unblocks a waiting consumer.The foregoing discussion raises some troubling questions. Exactly when does theblocked consumer continue? If immediately, then we may have two activities in themonitor at once, and our careful mutual exclusion is ruined. If later, then by the time itcontinues, some other consumer may already have taken the last datum, and the assumptionon line 32 that the buffer is not empty is wrong. If several consumers are waiting atthe same time, which one or ones are unblocked by a signal? If a producer executes asignal when no consumers are waiting, is this signal stored or discarded?Not all definitions of monitors in the literature agree on the answers to these questions.We will first present a common approach and then discuss alternatives. Figure 8.3expands the preceding figure to show the effect of conditions. For every condition webuild a condition queue (shown on the bottom of the monitor). We also introduce one

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

Saved successfully!

Ooh no, something went wrong!