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.

This paper discusses some of the major design decisions that distir~uish recent language proposals for concurrent programming, It is argued that the classification of languages as "procedurebased" or "message-based " is misleading, in that it confuses two independent issues. It is further argued that these issues are best left undecided by the language designer. 1. Iutroductioa The last few years have seen the creation o [ a large number of high-level languages for concurrent programming. Since the publishing of Lauer and Needharn's paper "On the Duality of Operating System Structures"[8] it has been fashionable to divide such languages into two categories: procedure-based languages and Inessage-based [an&uages. Unfortunately, at least t~e questions must be asked to determine the category in which a particular language belongs: I) Does the sender of a message continue execution immediately, or does it wait for a reply? 2) Are messages received explicitly by active processes, or does their arrival automatically trigger the execution of some spec[fled body of code? The rE'st of these questions involves the choice of a synchronization mechanism. The second is really a matter of syntax. I intend to show that the two questions are in fact 4.nW.epe~,t~e'n~; they give rise to jt~rur combinations of answers, not two. Moreover, there are applications in which each of the combinations is the method of choice, so a reasonable language nl~ht need to provide more than one. I will return to these claims in sections 4 and 5 after first discussing the issues of synchronization and message receipt in greater detail. 2. Synchronization Much recent effort has been devoted to the study of multi-eomputerso in which separate processors have no memory in common. On such machines, all interaction between processes must ultimately be achieved by means of messages. Because of this limitation, synchronization is subsumed in the semantics o [ the ~onH operation. This workw ~ ~p~edhy ~F ~tnumberMC~Sl~904~d ~Arpacon~actnumb~ N~141~IC1~87.

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.