An Operating Systems Vade Mecum

286 Concurrency Chapter 8To represent fair synchronization rules, we need some more tools. First, we willallow several path expressions to be in force at the same time, as long as they don’t mentionthe same procedures. Next, we will want to introduce intermediate procedures. Forsimplicity, we will use the following notation for these procedures:let procedure = sequence of proceduresLet’s illustrate this idea with a more complex readers-writers example.1 path TryRead | TryWrite2 path { StartRead; Read } | Write3 let TryRead = StartRead4 let TryWrite = Write5 let DoRead = TryRead ; Read6 let DoWrite = TryWriteReaders call DoRead, which expands to TryRead ; Read (line 5), which in turnbecomes StartRead ; Read (line 3). Similarly, writers call DoWrite, whichbecomes TryWrite (line 6), which in turn becomes Write (line 4). The StartRead proceduredoes not need to do any work; it is called only to allow us to synchronize the restof the operations. Line 2 expresses the constraints we want on simultaneous readers andwriters. Line 1 tells us that activities must wait their turn to start TryRead and TryWrite.This set of path expressions works, in that it properly excludes readers and writersfrom each other. It also enforces a policy, in that it takes readers and writers in the orderin which they appear, except that readers that arrive next to each other in line are allowedto overlap their executions. It is not easy to be convinced, however, that this policycomes out of these expressions.Implementing path expressions is not difficult; they can be converted to semaphoreoperations. However, we will not examine the conversion because it is complex. Luckily,a compiler can be expected to perform this work, so it can be done before the programis run, and the programmer need not deal with its intricacies.Since path expressions have the advantage of separating the synchronizationspecification from the routines themselves, the procedures that accomplish work (likeRead and Write) are uncluttered by extraneous considerations. Path expressions alsoavoid specialized guard procedures whose only purpose is to effect mutual exclusion andsynchronization. However, the procedures we introduced with the let clause serve muchthe same function.Like monitors, path expressions are not descriptive enough to describe the order inwhich blocked activities should be resumed. The either-or operator unblocks activities inthe order in which they arrive, which may not be the order desired.Let’s step back from the complex synchronization problems we have been examiningand try Figure 8.1. We can certainly impose extra constraints and require that all theactivities follow a prescribed order. If we wish to implement Figure 8.1 without extraconstraints, we will have to let the same procedure appear in several path expressions.We then get the following solution:1 path A ; B ; C ; F ; I2 path D ; E ; F3 path A ; D ; G ; H ; I4 path B ; E ; H