On Synchronizing Readers and Writers with Semaphores

J. L. Keedy and J. Rosenberg Department of Computer Science, Monash University, Clayton, Victoria, 3168, Australia. K. Ramamohanarao Department of Computer Science, University of Melbourne, Parkville, Victoria, 3052, Australia

A weakness in the reader priority solution proposed by Curtois, Heymans and Paraas for the problem of synchronizing Downloaded from https://academic.oup.com/comjnl/article/25/1/121/527286 by guest on 29 September 2021 concurrent readers and writers is described and an improvement is explained. The difficulties of solving complex synchronizing problems by using standard semaphore primitives, as illustrated by this example, lead us to propose that special-purpose synchronization techniques should be supported by a judicious combination of hardware/microcode and software routines. We then describe an efficient solution for the reader/writer problem which is easy to understand, to implement and to use.

integer readcount; (initial value = 0) INTRODUCTION semaphore mutex, w; (initial value for both = 1) READER WRITER A common synchronization problem occurs when a P (mutex); resource can be used in two modes, sharably by any readcount '= readcount + 1; number of 'readers' or exclusively by one 'writer' at a if readcount = 1 then P(iv); time. Curtois, Heymans and Parnas proposed two V'(mutex); solutions to the problem,1 one based on reader priority, the other on writer priority. In the first case no reader reading is performed writing is performed should be kept waiting unless a writer has already obtained permission to use the resource. In the second V(mutex); case, once a writer is ready to write he is given permission readcount = readcount — 1; to do so as soon as possible. Both solutions use P and V if readcount = 0 then V(w); operations on semaphores as the primitive synchroniza- V (mutex); 2 tion mechanism. Figure 1. Although the problem, in both its forms, is easy to understand, the proposed solutions are by no means minimum delay for readers (Fig. 1). Inspection of the straightforward. In fact Curtois et al. made special solution shows that when a writer is in its writing region mention of the effort involved in reaching their solutions the queue associated with w will contain zero or more and of the unreasonable complexity of earlier versions of writers and zero or one reader, so that when the writer their solutions. We attest to similar experiences in our releases w it is arbitrary whether another writer or a own investigations of the problem, which included a reader will be awakened. (Curtois et a/.'s discussion of reformulation of the reader priority solution in an attempt the writer priority case makes clear that no assumptions to remove an apparent weakness in the original version. about priority are built into the V operation). That the w We shall explain this weakness and present our alterna- queue can hold more writers than readers suggests that in tive solution as an illustration of the nature of some of the many cases a writer process might be selected in difficulties involved in this approach to the solution of preference to a reader. In other words the solution does synchronization problems and then propose an alterna- not guarantee that readers will experience minimum tive technique which removes most of the difficulties. delay.

AN EXAMINATION OF THE READER A revised reader priority solution PRIORITY SOLUTION Our solution, shown in Fig. 2 introduces an additional In this section we draw attention to a weakness in the binary semaphore extra which is claimed and released reader priority solution proposed by Curtois et al. and 1 only by writers. While a writer is in its writing region all suggest an improvement, thereby demonstrating some other writers are queued on extra, not on w. Thus when of the inadequacies of solving the problem using normal w is released the waiting reader, if any, will be awakened, semaphores. thereby removing the weakness in the original solution. As far as we can tell the solution appears to be correct A weakness in the reader priority solution (in some loose sense), but we have several reservations regarding both it and similar approaches to solving The aim of the.reader priority solution is to ensure complex synchronization problems. CCC-00KM620/02/0O25-O121 $02.50 © Heyden & Son Ltd, 1982 THE COMPUTER JOURNAL, VOL. 25, NO. 1,1982 121 J. L. KEEDY, J. ROSENBERG AND K. RAMAMOHANARAO

integer readcount; (initial value = 0) p-insXr (sent, condition); semaphore mulex, w, extra; (initial value of each = 1) it condition = 'sem < 0' then suspend (semqueue). READER WRITER The P macro P (mutex); readcount '= readcount + 1; P (extra); v-instr (sem, condition) if readcount = 1 then P(w); P (w); if condition = 'sem <; 0' then activate (semqueue). V (mutex); The V macro p-instr and u-instr are indivisible hardware/microcoded instructions; reading is performed writing is performed suspend and activate are indivisible queuing routines in the process scheduler. The testing of condition values in both cases assumes that P (mutex); the decrement/increment occurs before the value of sem is tested. readcount '= readcount — 1; if readcount = 0 then V(M>) ; V (extra); V (mutex); Figure 3. P and V macros based on hardware/microcoded operations. Figure 2. An improved reader priority solution. vate; suspend). The practicality of implementing such a (1) The problems are usually easy to state and simple to mechanism has been demonstrated in the ICL2900 Series Downloaded from https://academic.oup.com/comjnl/article/25/1/121/527286 by guest on 29 September 2021 understand; the solutions are usually complex and it and in other recent systems.9 is not easy to understand them nor to gain confidence Our basic solution for the readers/writers problem can in their correctness. be regarded as an extension of this technique. We (2) It is easy to waste much time and effort in solving propose that indivisible hardware/microcoded instruc- apparently trivial problems, and it is easy to make tions are provided to establish a claim for reading, read- mistakes. p, and for writing, write-p, and to release from reading, (3) The solutions are at best approximations. Consider, read-v, and from writing, write-v. In addition we extend for example, what is meant by a phrase such as 'a the indivisible 'activate' and 'suspend' primitives to reader is ready to read'. Our commonsense tells us support this case. In the following subsections we shall that it refers to the point at which the reader begins describe the proposed new primitives in detail, showing the reader entry protocol, i.e. when it executes the P that they can be efficiently implemented. We shall then (mutex) operation. But then if a writer exits his attempt to justify why this appears preferable to previous writing region after the reader has executed the P approaches. (mutex), but before he has reached the P(w) operation, it is possible that another writer may reach the P(w) operation first and thus gain access to his writing The microcoded instructions region although a reader 'was ready to read'. Similar problems with the writer priority solution have been The structure of a 'readers/writers semaphore', a type of discussed in the literature. A common approach has variable on which read-p, read-v, write-p. and write-v been to redefine operations on semaphores, making instructions operate, is shown in Fig. 4. The boolean them more powerful.3"7 Despite claims to the contrary it is not always easy to arrive at nor to understand solutions using extended semaphore primitives intended for general purpose use. Nor is it Current Waiting Waiting Current always easy to implement the proposed extensions on Readers Readers Writers Writer real computers. In the following section we propose an alternative and more practical approach. Figure 4. Structure of a readers/writers semaphore.

field current-writer indicates whether any writer is in its READER/WRITER SEMAPHORE PRIMITIVES writing region; the remaining integer fields count the number of processes waiting to read, currently reading The basic solution and/or waiting to write. The initial values of these fields are false and zero, as appropriate. Elsewhere, in connection with a different synchronization The indivisible hardware or microcoded operations on problem, we have described how P and V operations on these variables are outlined in a Pascal-like notation in semaphores can be efficiently implemented as two-part Fig. 5. Each procedure sets a local condition code operations: an indivisible hardware or microcode instruc- indicating whether a subsequent call must be made on tion (which decrements or increments a semaphore the queuing procedures (if true) or not (if false) in order variable and sets a condition code showing the result of to complete the required protocol. the operation) and an indivisible operation to suspend or It is the microcoded operations which determine when activate a process (which is typically a software routine 8 processes must be suspended and activated, and in implemented as part of the process scheduler). These consequence they determine the priority rules. Figure 5 operations are combined as shown in Fig. 3 to form actually describes the writer priority situation, but it is macro instructions which implement the P and V easily modified to reflect reader priority: read-v and write- operations. Notice that the suspend/activate operations P remain unchanged; in read-p the conditional expression must be commutative in the sense that each activate is reduced to if not current-writer then ...; the order of the wakes up exactly one process and that the sequence tests in write-v is changed so that waiting readers are (suspend; activate) has the same nett effect as

122 THE COMPUTER JOURNAL. VOL. 25, NO. 1,1982 © Heyden & Son Ltd, 1982 ON SYNCHRONIZING READERS AND WRITERS WITH SEMAPHORES

type readers-writers-semaphore = record current-readers: 0 ... # processes; waiting-readers: 0... # processes; waiting-writers: 0 ... # processes; current-writer: boolean; end; procedure read-p (r-w-sem: readers-writers-semaphore; condition-code: boolean); begin with r-w-sem do if not current-writer and waiting-writers = 0 then begin current-readers '= current-readers + 1; condition-code = false end else begin waiting-readers '= waiting-readers + 1; condition-code = true end end; procedure read-v (r-w-sem: readers-writers semaphore; condition-code: boolean); begin with r-w-sem do

begin current-readers '= current-readers — 1; Downloaded from https://academic.oup.com/comjnl/article/25/1/121/527286 by guest on 29 September 2021 if current-readers = 0 and waiting-writers > 0 then begin current-writer = true; waiting-writers '= waiting-writers — 1; condition-code = true end else condition-code = false end end; procedure write-p (r-w-sem: readers-writers-semaphore; condition-code: boolean); begin with r-w-sem do if current-readers = 0 and not current-writer then begin current-writer '= true; condition-code = false end else begin waiting-writers = waiting writers + 1; condition-code = true end end; procedure write-v (r-w-sem: readers-writers-semaphore; condition-code: boolean; read-count: 0 .. .# processes); begin with r-w-sem do if waiting-writers = 0 then begin current-writer = false; if waiting-readers = 0 then condition-code = false else begin current-readers '= waiting-readers; waiting-readers = 0; read-count = current-readers; condition-code = true end end else begin waiting-writers'= waiting-writers — 1; read-count =0; condition-code = true end end;

Figure 5. The hardware/microcoded instructions on readers/writers semaphores.

These algorithms are much simpler and easier to normal semaphores, mentioned in the section on 'The understand than those discussed in our examination of Basic Solution'. the reader priority solution, and they do not contain the The activation operation which we propose is an ambiguities of those solutions. For example in the writer extension of that required for normal semaphores, in that priority case, priority is unambiguously guaranteed from the caller supplies a further parameter indicating how the point at which a writer is 'ready to write', i.e. as soon many processes must be activated:

macro read-claim (x: reader-writer-semaphore); et al. solution requires up to 3 calls in the best case var c-c: boolean; (exiting from a read section) and up to 7 calls in the worst begin read-p (x, c-c); if c-c then suspend (reader-queue) case (entering a read section). Furthermore that solution end; requires space to be allocated for 5 semaphore variables macro read-release (x: reader-writer-semaphore); and 5 queues, whereas one 32-bit word and two queues var c-c: boolean; suffice for our solution. We have no doubt that our begin read-v (x, c-c); proposal is far more efficient in terms of space, execution if c-c then activate (writer-queue, 1) end; time and reduced overheads on calling and executing the macro write-claim (x: reader-writer-semaphore); scheduler routines. var c-c: boolean; While we have described the suspend and activate begin write-p (x, c-c); routines as if they should be implemented in software, we if c-c then suspend (writer-queue) end; do not exclude the possibility of implementing them macro write-release (x: reader-writer-semaphore); partly or completely in microcode to gain further var c-c: boolean; efficiency improvements. This might be achieved by rcount: 0 . . . # processes; providing general-purpose indivisible queuing opera- begin write-v (x, c-

CONCLUSION be commutative, so that readers might be delayed indefinitely. Finally it should be noted that neither the In our examination of the Reader Priority Solution we scheduling routines nor programs using the macro demonstrated some of the difficulties involved in using operations reflect any knowledge of the priority rule. normal semaphores as the primitive synchronization mechanism for solving the readers/writers problem. Solutions are not easy to reach and are not easy to IMPLEMENTATION CONSIDERATIONS understand. Furthermore they can at best be regarded as approximations. While others have attempted to over- Readers familiar with modern microcoded processors come such problems by proposing general purpose will realize that the algorithms described in 'The modifications to the operations on semaphores3"7 we Microcoded Instructions' can be efficiently implemented have reached the conclusion that general purpose in microcode. Consider the case of a 32-bit word mechanisms are often neither easy to use nor easy to computer with multiple processors sharing a common implement. memory, supporting up to 255 concurrent processes. Our own approach starts from the recognition that In such a system the format of a readers/writers there are different classes of synchronization problems semaphore would best be represented as a single word in which, if supported by a judicious combination of which the waiting-readers, current-readers and waiting- hardware/microcode/software can be both efficiently writers fields would each occupy an 8-bit byte and the implemented and easy to use at a high level of abstraction. current writer field would use one bit of the remaining Another example of this is the proposal for 'resource set byte. Indivisibility of the operations could be guaranteed semaphores', which provide a simple and efficient by accessing the semaphore in main memory using technique for allocating equivalent resources.8 The 'interlock read' and 'interlock write' operations, cf. VAX practicality of this technique has since been proved in 11-780.10 The microcoded operations would be trivial if the MONADS I operating system.1314 The present for example the semaphore's fields were manipulated proposal extends this approach to encompass the using four internal registers. reader/writer problem. We have actually microcoded the operations for writer It seems to us that this problem is sufficiently pervasive priority using a HP2100 system.11 This is less suitable to justify a special purpose solution. It appears very than the environment just described, since words have 16 frequently in operating system design (e.g. in control of bits, only one word of memory can be accessed at a time, access to internal tables, to file directories) and just as and byte handling is expensive. Nevertheless the new frequently in the design of file systems and database operations typically execute in 14 usec. This compares systems. In practice many designers reduce the problem with 7 usec for the microcoded first part of P and V to one of mutual exclusion; but in doing so they operations on general semaphores. potentially lose some of the parallelism which might To execute the Curtois et al. writer priority solution on otherwise be achieved, and this could be critical in a high the HP 2100 with the assistance of microcoded P and V throughput or real-time system. instructions requires approximately 60 usec per protocol, We have deliberately not argued the merits of choosing compared with 14 usec for our proposal. These figures the reader priority or the writer priority solution. While exclude calls to, and execution of, the scheduling routines. the writer priority solution is probably more generally With the latter included the superiority of our proposal useful, there are undoubtedly cases where reader priority becomes even clearer, because each of our operations is more suitable. Fortunately we are not forced to choose requires at most one scheduling call, whereas the Curtois between the two. It is a trivial extension of our proposal

124 THE COMPUTER JOURNAL, VOL. 25, NO. 1,1982 © Heyden & Son Ltd, 1982 ON SYNCHRONIZING READERS AND WRITERS WITH SEMAPHORES to include an additional boolean variable in each MONADS Operating System and its supporting hard- reader/writer semaphore, initialized to indicate whether ware, incorporating the proposed technique. Initial reader or writer priority is to be applied to the particular results confirm our view that it is easy to implement and resource controlled by the semaphore. This will be tested to use, and that it provides an efficient solution for the in the read-p and write-v operations (see 'The Microcoded synchronization of readers and writers. Instructions'); very little additional microcode is required to cover both cases. The great benefit is that the caller need not be aware of the priority requirements and code Acknowledgments them into his program (which is necessary with the standard semaphore solution). Instead the same code can Figure 1 is reprinted from Curtois et al.x by permission of the be linked to different objects which operate with different Association for Computing Machinery. The work described in this paper was supported by grant F77/15337 from the Australian Research priority requirements. Grants Committee and by grant SC 18/79 from the Monash Special At present we are developing new versions both of the Research Fund. Downloaded from https://academic.oup.com/comjnl/article/25/1/121/527286 by guest on 29 September 2021 REFERENCES

1. P. J. Courtois, F. Heymans and D. L. Parnas, Concurrent control 9. J. L. Keedy, An outline of the ICL 2900 series system with 'readers' and 'writers'. Communications of the ACM 14 architecture. Australian Computer Journal 9 (No. 2), 53-62 (No. 10), 667-668 (1971). (1977). 2. E. W. Dijkstra, Cooperating sequential processes, in Program- 10. Digital Equipment Corporation, VAX11-780 Architecture ming Lanuages, ed. by F. Genuys, Academic Press, London Handbook. Digital Equipment Corporation (1977). (1968). 11. Hewlett Packard, 2100A Computer Reference Manual. Hewlett 3. V. G. Cerf, Multiprocessors, Semaphores and a Graph Model of Packard Company 02100-90001 (December 1971). Computation, ENG-7226, Computer Science Department, 12. B. H. Liskov, The design of the Venus operating system. University of California, Los Angeles (1972). Communications of the ACM "\S (No. 3), 144-149 (1972). 4. H. Vantiborgh and A. van Lamsweerde, On an extension to 13. J. L. Keedy and J. Rosenberg, On the Handling of the Low Dijkstra's semaphore primitives. Information Processing Letters Level System Processes, MONADS Report No. 6, Department 1,181-186(1972). of Computer Science, Monash University, Melbourne (1979). 5. P. Wodon. Still Another Tool for Controlling Cooperating 14. J. Rosenberg, The concept of a hardware kernel and its Algorithms, Department of Computer Science, Carnegie Mellon implementation on a minicomputer. PhD. Thesis, Monash University (1972). University, Melbourne (1979). 6. T. Agerwala, Some Extended Semaphore Primitives. Ada 15. P. J. Denning and T. D. Dennis, On minimizing contention at Informatica 8, 201-220 (1977). semaphores. ACM Operating Systems Review 14 (No. 2), 9- 7. R. Conradi, Some comments on 'concurrent readers and 16(1980). writers'. Ada Informatica 8, 335-340 (1977). 8. J. L. Keedy, K. Ramamohanarao and J. Rosenberg, On Received February 1981 Implementing Semaphores with sets. The Computer Journal 22 (No. 2), 146-150(1979). ©Heyden& Son Ltd, 1982