An Operating Systems Vade Mecum

Mechanisms 285A completely different way to describe synchronization is to spell out what routines maybe called, and in what order, separately from the routines themselves. We will introducea syntax known as path expressions that specifies all temporal relationships among invocationsof procedures that control shared data. These expressions are built out of procedurenames and connectors that indicate restrictions. For our examples, we will dealwith the readers-writers problem and use procedures such as Read, Write, and StartRead.The simplest expression has just one procedure name:path ReadThis expression means that only one activity may call Read at a time but that when Readis finished, another activity (or the same one again) may call it again. That is, when thepath expression is finished, it may be started again. If we want to specify that Read mustbe surrounded by StartRead and EndRead, we can saypath StartRead ; Read ; EndReadThe semicolon operator indicates that after one procedure has finished, the next one maybe called. Equivalently, this operator indicates that before a particular procedure may becalled, the one before it must have finished. However, it does not require that the sameactivity that calls StartRead must call Read.To indicate that any number of activities can simultaneously perform the same procedure,we surround that procedure in brackets, as shown here:path { Read }This path expression says that any number of simultaneous uses of Read are permissible.If some activities are in Read, a new one may join them. When they all finish, the pathexpression is finished and may be started again.The last operator is the ‘‘either-or’’ operator, which we will write as a vertical bar,as in the following example:path Read | WriteThis operator means ‘‘the left side or the right side may be active, but not both.’’ Thisparticular path expression specifies that one activity may read at a time and one maywrite at a time, and reading and writing exclude each other. After either finishes, anyactivity may start doing either again. We assume that activities that wish to Read orWrite are served in arrival order; no activity is caused to wait forever for an either-oroperator.We can combine these operators to form more complex expressions. For example,the following begins to address the actual readers-writers problem:path { Read } | WriteThis expression lets any number of readers alternate with a single writer. Although thisexpression represents exactly the restriction we want, it is not fair to writers. If readeractivities arrive fast enough so that there is always some activity in the ‘‘{ Read }’’ partof the path expression, writers will never be allowed to start.This solution also has the danger that a reader will want to perform several reads ina row. A writer could be serviced between two reads, and inconsistent data would beread. To avoid this problem, we will assume that each reader wants to read only once.Similarly, we will assume that each writer wants to write only once. Otherwise, wherewe say Read, we could understand that to mean ‘‘perform any number of read operationsin the same activity.’’ Likewise, we can understand Write to mean ‘‘perform any numberof read or write operations in the same activity.’’