experience with strongprocessesstrong and monitors in mesa.pdfVIP

Experience with Processes and Monitors in Mesa1 Butler W. Lampson Xerox Palo Alto Research Center David D. Redell Xerox Business Systems Abstract The use of monitors for describing concurrency has been much discussed in the literature. When monitors are used in real systems of any size, however, a number of problems arise which have not been adequately dealt with: the semantics of nested monitor calls; the various ways of defining the meaning of WAIT; priority scheduling; handling of timeouts, aborts and other exceptional conditions; interactions with process creation and destruction; monitoring large numbers of small objects. These problems are addressed by the facilities described here for concurrent programming in Mesa. Experience with several substantial applications gives us some confidence in the validity of our solutions. Key Words and Phrases: concurrency, condition variable, deadlock, module, monitor, operating system, process, synchronization, task CR Categories: 4.32, 4.35, 5.24 1. Introduction In early 1977 we began to design the concurrent programming facilities of Pilot, a new operating system for a personal computer [18]. Pilot is a fairly large program itself (24,000 lines of Mesa code). In addition, it must support a variety of quite large application programs, ranging from database management to inter-network message transmission, which are heavy users of concurrency; our experience with some of these applications is discussed later in the paper. We intended the new facilities to be used at least for the following purposes: Local concurrent programming. An individual application can be implemented as a tightly coupled group of synchronized processes to express the concurrency inherent in the application. 1 This paper appeared in Com