An Operating Systems Vade Mecum

288 Concurrency Chapter 822 procedure PutBuffer(What : Datum);23 begin24 Buffer[NextIn] := What;25 NextIn := (NextIn + 1) mod Size;26 end PutBuffer;2728 procedure GetBuffer(var Result : Datum);29 begin30 Result := Buffer[NextOut];31 NextOut := (NextOut + 1) mod Size;32 end GetBuffer;We have repeated the entire module to show how simple the PutBuffer and GetBufferprocedures have become. As with path expressions, we find that moving all the synchronizationout of the procedures clarifies the entire program. Our invariant expressionsare in lines 13 through 20. Line 14 restricts calls to PutBuffer by requiring that enoughcalls to GetBuffer have already happened so that the buffer won’t be overfilled. Similarly,line 18 restricts calls to GetBuffer by requiring that enough calls to PutBuffer havealready happened so that the buffer has some data to be removed. Lines 16 and 20 restrictboth PutBuffer and GetBuffer to allow only one activity in either.We can also use invariant expressions to represent a solution to the readers-writersproblem. We will show just the invariants and omit the rest of the module.invariant ReadCurrentCount(Write) = 0invariant WriteCurrentCount(Write) + CurrentCount(Read) = 0We might make the same assumption we did for path expressions: that activities forced towait because of an invariant are unblocked, if possible, in arrival order. Therefore, ifseveral readers and writers arrive while a writer is active, all are blocked. When thewriter finishes, one reader or writer, whichever came first, is allowed to start. However,while one activity is reading, any number of readers may start; only writers are blocked.The solution just shown may starve writers. To give writers precedence, we needto prevent new readers from starting if there are any waiting writers. The followinginvariant expressions serve this purpose:invariant ReadWaitCount(Write) + CurrentCount(Write) = 0invariant WriteCurrentCount(Write) + CurrentCount(Read) = 0The only change is an extra clause in the invariant expression for Read.Invariant expressions are easily used to represent the synchronization graph of Figure8.1. For example, the invariant expression for procedure E would be as follows:invariant EFinishCount(B) + FinishCount(D) = 2Invariant expressions, like path expressions and monitors, are unable to reorderwaiting queues to serve some activities out of turn. However, they are often far clearerthan path expressions and can express the same sort of synchronization constraints.