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 28135 procedure Read;36 begin37 ... { actually read from the shared data }38 end Read;3940 procedure Write;41 begin42 ... { actually modify the shared data }43 end Write;4445 end ReadWriteIn lines 6 and 7, we declare two crowds called Readers and Writers. Activities can bemembers of these crowds. <strong>An</strong>y member of Readers may access the Read procedure(lines 35−38), and any member of Writers may access both the Read and the Write procedure(lines 40−43). Activities initially belong to no crowds. The guard procedures,which are mutually exclusive as before, decide when it is appropriate for an activity toenter or leave a crowd. They may use conditions to wait for the right situation. Whenthe guard procedure decides to let a reader proceed, it executes enter for the Readerscrowd (line 12). Similarly, a guard can let a writer enter the Writers crowd (line 25).Although any activity may call Read and Write, since they are exported from the monitor,a run-time check prevents activities from calling ordinary procedures that are invisibleto the crowds they are in. A member only of Readers may not call Write. However,a member of Writers may call either Read or Write, since both are specified in thedefinition of Writers (line 7).It is easy to implement crowd monitors once regular monitors have been implemented.A run-time check is applied every time an activity calls a procedure like Readand Write in order to make sure that the activity is in the necessary crowd. If not, a programerror has been discovered. No new blocking or unblocking rules are needed.2.11 Event counts and sequencersSo far we have investigated methods that serve for both mutual exclusion and synchronization.We now turn to a technique to achieve synchronization without requiring mutualexclusion. Mutual exclusion is not always desirable because it limits concurrency. It isalso difficult to enforce, as we have seen, and is not always needed on physically distributedcomputers. In fact, if one hasn’t yet implemented mutual exclusion, the method weare about to discuss can be used to build semaphores to provide mutual exclusion, too.The semaphores we can build will even allow simultaneous Down operations on severalsemaphores.The first tool we will introduce is the event count. <strong>An</strong> event count is representedas a non-decreasing integer variable, initially 0. It keeps a count of the number of eventsof interest to the program, such as the number of times a variable has been modified. Asan abstract data type, event counts have three operations: Advance, Read, and Await.Advance(E) is used to signal the occurrence of events associated with event countE. It has the effect of incrementing E atomically.

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

Saved successfully!

Ooh no, something went wrong!