Adapting Modula-2 for distributedsystemsby P. V. Mellor, J. M. Dubery and D. G. Whitehead

Modula-2 is a recently developed concurrent programminglanguage designed primarily for implementation on a mono-processor. This paper reports on the changes found necessary,both to the source language and to the support environment, inorder to allow the language to be used to program a tightlycoupled, homogenous, distributed computing system. Specificareas covered are: the allocation of program code and data toprocessors, which is kept independent of the source code, allowingflexible re-allocation without re-compilation; the choice of an inter-processor communication mechanism, where the remoteprocedure call was considered to be the most flexible technique;and the selection of an inter-process communication mechanism,where, despite the distributed nature of the target, the monitor wasfound most suitable.

1 Introduction

As the cost of powerful micro-processors has fallen it has becomeincreasingly attractive to constructmultiple-processor computers for real-time control applications. As anexample, the Robotics Research Unit atHull University found that the increasingdemand for 'intelligent' robotic sensorscould best be met by the construction ofa tightly coupled distributed computingsystem (Ref. 1). Consequently, a greatdeal of research effort is currentlyaimed at producing effective program-ming languages for such systems.Although existing languages such asModula-2 (Ref. 2), Ada (Ref. 3), Con-current Pascal (Ref. 4), and CSP (Ref. 5)are considered to have some potentialfor distributed systems, current im-plementations aim at providing con-current programming facilities for asingle computer, and do not generallysupport the concept of a multiple-pro-cessor target architecture.

184

Wirth, the designer of Modula-2, says:'. . . Modula-2 is designed primarily forimplementation on a conventional single-processor computer. For multiprogram-ming it offers only some basic facilitieswhich allow the specification of quasi-concurrent processes and of genuineconcurrency for peripheral devices.' Hav-ing used Modula-2 for some time (ETHcompiler running on a DEC PDP-11/23),we felt that it would be suitable for use in adistributed environment. This paper givesa justification of our approach anddescribes the modifications and supportwe found necessary to adapt Modula-2 torun on our distributed architecture. Thisarchitecture is described in more detaillater, but its important characteristics arethat it consists of a homogenous set ofprocessors with fast communications andno common memory.

When considering multiple-processorarchitectures an important question thatarises is one of allocation, i.e. decidingwhere each section of the program shouldreside and which processor(s) should

have access to it. Changing the allocationcan have a -profound effect on theefficiency of the program but should not,in theory, affect the correctness. However,in a real-time system, where program cor-rectness often depends upon meetingstringent timing constraints, a bad alloca-tion can result in timing constraints beinginvalidated, and thus in program failure.Current research in this area is not yet atthe stage where a theoretical solution canbe implemented (Ref. 6), and so we havedesigned our programming system insuch a way that allocation can proceediteratively (i.e. allocate, execute, re-allo-cate) and independently of the codingprocess, as outlined in Ref. 7, rather thanbeing specified in the source code as inStarMod (Ref. 8). This has been animportant aim of our work.

The paper is organised as follows. Thefollowing Section describes the overalloperation of the system, Section 3 dis-cusses issues relating to the allocation ofprogram units to actual processors, andSection 4 examines the implications thatthe physical distribution has on the cor-rectness of programs. Section 5 outlinesthe implementation and expected futuredevelopments. It should be noted that theremainder of this paper assumes that thereader is already familiar with theModula-2 programming language andsupport environment.

2 General operation

This Section outlines the operation of thesystem by considering the major softwarecomponents. It should be read in con-junction with Fig. 1, from which it can beseen that the programmer prepares thedefinition (.DEF) and implementation

Software Engineering Journal September 1986

(.MOD) modules and submits them to thecompiler to obtain the relevant link (.LNK)files as normal. When all the necessarymodules have been compiled they areprocessed by a builder, which creates asmall database for this specific link in a'static analysis file' (.SAN). This file canthen be submitted to a linker/allocator,which allocates modules to processorsand creates a distributed task image(.DTI) from the code obtained by a secondpass of the link files. Execution can thentake place after this file has beendownloaded.

2A Compilation

From the outset we establish an import-ant prerequisite: it should be possible todesign and code programs using stan-dard Modula-2 as far as possible. Modulescan then be independently tested anddebugged as normal, and almost no refer-ence is made in the source code to theeventual distribution of the program. Adifference from standardModula-2 arises,however, when the program is to belinked, since it is at this stage that modulesmust be assigned to the various pro-cessors, which we will refer to as (hard-ware) nodes.

2.2 Building

The linker has been split into two sep-arate programs: a builder and a linker/allocator (although the linker and allo-cator have been implemented as a singleprogram, the term 'allocator' will be usedwhen referring to that part of linker oper-ation that is concerned exclusively withallocation). The builder takes as input thename of the master module, from which itlocates and processes all the modulesthat are needed in the current link. Thisprogram performs all the linker functionsthat are independent of the allocation, andthus need be done only once. The outputis a 'static analysis' file (of file type .SAN onthe PDP-11) which contains informationrelating to the static nature of the pro-gram, i.e. the sizes of procedures and datasegments, relationships between pro-cedures and owning/calling modules, andso on. If a base option is used with thebuilder, then the static analysis file for thebase is input first, on top of which infor-mation relating to the current link is addedto produce the new .SAN file.

2.3 Allocation and linking

The allocator takes the .SAN file asinput and first performs an allocation.This allocation can be done either auto-matically or interactively, with the alloca-tor querying the user on a module-by-module basis in order to obtain thedestination node on which that module

IDEFJsourcefile

compiler

sourcefile

IDEFJ

base

builder

vunallocated

SAN

linkerallocated

down loader

hardware a -file

program

Fig. 1 General operation of major software components

will execute. When this has been per-formed the modules are linked and a 'dis-tributed task image' (.DTI) file is producedfrom the code obtained by a second passof the original link files.

The linker also produces a new .SANfile to replace the old one. The format is asbefore, but now the file contains theaddresses of each procedure and datasegment as well as the nodes to whichthey have been allocated. After beingdownloaded and tested, a program can bere-allocated and linked without having tobe re-compiled or re-built. In this case the.SAN file opened contains the previousallocation information, which would beused by the allocator as a default, if sorequired. Consistency of file versions ismaintained by a set of keys which aregenerated and checked automatically.

2.4 Inter-node communication

In our system, program parts on dif-ferent nodes may communicate only byremote procedure calls (Ref. 9). At runtime, any procedure calls that occurbetween modules on different nodes arehandled by the remote procedure callmechanism, which maintains the samesyntax and semantics as local procedurecalls. The node wishing to perform the callis referred to as the 'client' node, whereasthe node which actually performs the call(and contains the procedure code) isreferred to as the 'agent' node. When aremote procedure call occurs the clientprocess is suspended, the actual par-ameters are transmitted, an agent pro-cess (acting on behalf of the client)performs the call at the remote node, theresult parameters are returned and theclient is re-activated. A run time support

sub-system implements the remote pro--cedure calls (see Section 5).

In contrast to this, inter-node data refer-ences are not allowed. Modules sharingdata (whether static or dynamicallyscoped data) will be allocated to the samenode. Note that at the language level allconcurrency is expressed by the normalModula-2 constructs; nothing new isadded by the inter-node communicationmechanism.

3 Allocation issues

The aim of the system is not only to allowModula-2 to run on multiple-processortargets, but also to separate the (iterative)stages of program coding and allocation.As mentioned previously, allocation infor-mation (i.e. information relating modulesto actual hardware nodes) has been omit-ted from the source code. This gives theprogrammer a valuable aid: the ability towrite programs independently of theeventual allocation, and to be able tochange the allocation at will, without theneed for re-compilation. This Sectiondescribes the issues involved in thisallocation process: which segments ofcode are to be allocated; why this alloca-tion needs to be iterative; and what sup-port is needed, both at the source leveland at run time.

3.1 Allocation units

Global-level modules were chosen tobe the unit of allocation. There are threereasons for this. Ths first is that the pro-cedures of a module need efficient accessto the local shared data of the module: itwould not be possible to achieve this effi-

Software Engineering Journal September 1986 185

ciency if the system had been designedsuch that a module could be split overseveral nodes. Secondly, the module isconceptually best treated as an object initself, and it thus seems intuitively obviousto use it as the allocation unit, rather thanintroducing another scoping operator.The final, and probably most important,reason is that modules often form moni-tors (Ref. 10) where mutual exclusion ofprocesses is to be maintained, and thiswould be difficult to implement if a mod-ule itself was spread over several nodes.

It would be possible to allocate localmodules independently of the modules inwhich they are declared (which maythemselves be local), but since this wouldhave introduced considerable complica-tions it is not supported. The subject istreated in more detail later, in Section 3.5.

3.2 Re-allocation

The ability to re-allocate programs effi-ciently has several advantages:

• Program performance can beoptimised for the complete hardwareconfiguration present, and any specialfunctions available in the hardware (suchas specialised co-processors) can beexploited.• Programs can be developed andtested without the need for the full targethardware, and when 'correct' can easilybe re-allocated and run on the true target.Moreover, they are more transportableand changes in hardware are easy toaccommodate.• Program performance can beoptimised for the task at hand. Some pro-grams that are, for example, mainlysequential in nature may be best suited toan allocation which minimises the inter-node communication; whereas othersmay be best allocated in such a way as tofully exploit the true concurrency avail-able, even with the added communicationoverhead which this often involves.• Given that actual run time informationcan be obtained from the program, a bet-ter allocation may be quickly derived.

3.3 Communication restrictions

Modules are allocated to nodes aftercompilation, at link time. Furthermore,when the program executes it must becorrect, regardless of the allocation that isactually selected. Thus the semantics ofvariable access and procedure calls mustbe consistent for all legal allocations. Thishas been achieved by forbidding alloca-tions that would result in remote dataaccess (since this is not allowed), and bythe implementation of a remote pro-cedure call facility.

At compile time the programmer isunaware if procedure calls between mod-ules are local or remote; indeed it makes

no difference since the semantics areidentical. In this way the language can bekept independent of the eventual alloca-tion. We believe that it is in general badprogramming practice to export variablesfrom modules and that this should bedone only on the grounds of efficiency. Ittherefore seems inappropriate to imple-ment a remote variable access mecha-nism since this would be inefficient itself,and the programmer can always accessthese variables via remote procedure calls(and hence, if required, can make them'read only'). This does not mean that vari-ables cannot be exported; they can, butthis export cannot occur between mod-

Absolute binding is the binding of a mod-ule to a node because, for example, itaccesses input/output devices, or waits oninterrupts specific to that node.

Relative binding:Relative binding is detected by the com-

piler and the fact that it exists isrepresented in the link file and forms anallocation restriction. Since this restric-tion is detected at compile time we forcethe programmer to be aware of it at thistime. Thus any global-level import thatimplies binding to the imported modulesmust include a keyword to reflect this. Thenew syntax is:

import = [FROM ident] IMPORT [TIGHT] IdentList ";".

ules residing on different nodes. Hence ifvariables are exported then their impor-ters will be allocated to the same node.

Other restrictions are also imposed onthe type of parameters that can be passedto procedures that reside on separatenodes. Since each node has a separateand independent heap, pointers have rel-evance only on the node that defines themand therefore cannot be contained in anystructures passed as parameters betweennodes. Similarly, the remote procedurecall mechanism does not support remotecalling of procedure variables, and sothese are also illegal for inter-node trans-mission. Note that transmission of hiddentypes between nodes is allowed since theycan be accessed only by the definingmodule. Modules that import hiddentypes cannot de-reference them, sincethey have no information as to what theypoint to.

The keyword TIGHT must appear in theimport list of only global-level modules; itspresence in local level import lists istreated as an error.

When the 'FROM ident' is present theIdentList is checked, and if any of theitems require tight import (i.e. they arevariables or procedures whose par-ameters contain procedure types,pointers, or ADDRESS types) then the'TIGHT' keyword must be present. In theabsence of the 'FROM ident' the compilerchecks each qualified identifier as it isused, and any that require tight import areflagged as errors unless the qualifyingmodule was imported with the 'TIGHT'keyword present.

Absolute binding:Similarly, to reflect this binding the

module heading must contain an extrakeyword identifier. The new syntax is:

CompilationGnit = DefinitionModule J [FIXED]

[IMPLEMENTATION] ProgramModule.

At first these restrictions may seem tolead to the possibility of errors that thecompiler cannot check, since allocationinformation has been omitted from thesource. As outlined in the following Sec-tion, however, binding information is pre-sent in the source code (even thoughallocation information is not) and placesrestrictions on the link time allocationpossibilities that the allocator will laterdetect and enforce. That is, if a moduleimports some data from another module,or uses procedures whose parameterscontain types invalid for transmission,then the allocator guarantees that they willbe allocated to the same node.

3.4 Module binding

There are two classes of binding thatneed to be considered: relative and absol-ute. Relative binding is the binding of twomodules together because of the natureof the imports that exist between them.

Absolute binding of a module is needed topermit the use of absolute variables (i.e.those assigned to an absolute address bythe programmer) and IOTRANSFERstatements in that module, since the pres-ence of these items implies that the mod-ule will be required to run on a restrictedset of nodes.

The actual node to which the modulewill be bound is specified later, duringallocation, rather than in the implementa-tion module. Absolutely bound modulescannot be re-allocated automatically andwill remain bound to their initial nodeunless specifically moved at allocationtime. It is worth noting that erroneousresults can occur if values are coercedinto pointers, which are then de-refer-enced in order to access absolute physi-cal locations. This is because the modulemay not be a FIXED module and hencemay be allocated to a node where theobject to be accessed does not exist. It isnot possible to prevent this, however,

186 Software Engineering Journal September 1986

without imposing severe restrictions onthe type transference operators ofModula-2.

An interesting question here is: doesthe hardware support the software or viceversa? If the hardware supports the soft-ware (fo: example by providing a floating-point processor or a specific amount ofmemory), then the bound modules can ingeneral be placed on any node which hasthe required facilities. If the software sup-ports the hardware (for example terminaldrivers, dedicated input/output), then acopy of the bound module may be neededon every node that contains the relevanthardware. The lack of a parametrisedmodule instantiation feature in Modula-2is a considerable draw.back in this respect.This is also the case when general supportmodules (such as the kernel, messagepassing system, storage handler, whichare also written in Modula-2) have to beresident in each node and cannot consistof instantiations of single 'template' typemodules. We feel that our implementa-tion of the Modula-2 language would ben-efit from such a feature.

Owing to the presence of both absoluteand relative binding a program can becoded in such a way that it is not possibleto allocate it even after a successful com-pilation. Further, if the target hardware isrestricted or is significantly different fromthat for which the program was originallydefined, the only allocations which arepossible may not be implementableowing to the lack of resources on thatnode (primarily memory shortage). In thiscase there is no recourse but to re-codethe program. Since the compiler onlysees one part of the program at a time it isimpossible to detect this situation at com-pile time.

3.5 Local modules

As noted previously, although it wouldbe possible to allocate local modulesindependently, it has not been supportedin the current design. This is because itadds extra complexity and is not neces-sary, since the module can be madeglobal if the programmer wishes to allo-cate it independently.

The extra complexity arises from twosources. First, although tight importcould easily be extended to local mod-ules, there must also be a tight exportoperator, since the exported, as well as theimported, objects may imply a relativebinding between the local module and thenext outermost module. Secondly, if alocal module wishes to export an object toanother local module at the same nestinglevel, then it can only do so by making thatobject visible in the surrounding scope,i.e. in the next outermost module. If theobject required tight export then the outermodule would be bound to the local mod-

ule even if it did not use the object thatcaused the binding to occur.

4 Language issues

This Section addresses the languageissues that arise owing to the fact that theprogram modules are to be distributed onto separate processors.

4.1 Inter-process communication

The use of the remote procedure callnecessarily involves an active unit on oneprocessor, i.e. the process, calling for theservice of a passive unit on a second pro-cessor, i.e. a procedure. Thus an unex-pected consequence of our technique oftaking advantage of distributed proces-sing power is that the process can noweffectively migrate between processors.This is in contrast to what currentlyappears to be the expected inter-nodecommunication technique: channels orrendezvous. Here two (active) processessynchronise their activity when they wishto communicate, say, by engaging in arendezvous. However, this techniquerequires both inter-process and inter-node communication to be one and thesame, and we believe that this brings dis-advantages in un-natural structuring andinflexibility. Our technique avoids this.

In such a system, where inter-nodecommunication and inter-process com-munication are synonymous, the processbecomes the allocation unit, since dif-ferent parts of a process cannot reside ondifferent nodes. Also, the smaller andmore numerous the allocation units are,the more effective the allocator can be.Consequently, using channels or ren-dezvous implies that the program becoded as a large number of processes notfor the sake of concurrency, but to allowbetter allocation. For example, an essen-tially sequential program that needs to runon a distributed target (in order, forexample, to access several input/outputdevices available on different machines)would have to be coded into 'un-neces-sary' processes to allow it to reside in thedifferent nodes available. The program-mer thus implicitly embeds into the pro-gram a knowledge of the targetachitecture.

In contrast to this, in our system themapping of processes to nodes is notdefined; i.e. a node may execute severalprocesses, and conversly a process maycall for the execution of code on severalnodes. This separates the issues of inter-node communication and inter-processcommunication, allowing the program-mer to use process structure to representthe parallelism inherent in the task, ratherthan in the hardware.

A second point is one of efficiency.When inter-node communication andinter-process communication are the

same and the program is re-allocated torun on a smaller set of nodes, then theinter-node communication mechanismwould remain but would now operate on asingle node; this is often inefficient. In ourscheme, however, the remote procedurecall operation simply reverts back to anormal procedure call, which is veryefficient.

4.2 Monitors

Modula-2 provides an extremely smallset of primitives for concurrency whichcan then be built into a usable processscheduler. A typical, indeed almost stan-dard, form of inter-process communi-cation is by monitors (which providemutual exclusion) and signals (whichprovide synchronisation), although otherschemes can also be implemented (Ref.11). It was decided to use a monitor-based scheme in our implementation,supplemented with remote procedurecalls, rather than adopt a different method— such as channels (Ref. 5) or ren-dezvous (Ref. 3) — more commonlyfound in distributed systems.

If the processes that communicate viathe monitor are on the same node, thenthe situation is identical to that found inthe original Modula-2, and the monitoroperates as normal. If, however, the pro-cesses are on different nodes, then aremote call will have to occur on a moni-tor entry procedure. When this happensan agent process is assigned to performthe call on the destination node. Since thisprocess is now executing on the samenode as the monitor, the monitor still per-forms properly.

As has been noted previously (Ref. 12)problems can arise when monitors callexternal procedures. This comes from thefact that mutual exclusion is often guaran-teed by having a non-pre-emptive sched-uler, with interrupt lock-out to forbid pre-emption from processes that are waitingon interrupts. Thus, in critical sections, aprocess would yield the processor only atconsistency points. It can be seen that if aprocedure call to another module occursin a critical section, then there is in generalno way of knowing whether the called pro-cedure chain will involve a processorre-schedule or not, and thus it is wise torestrict such calls to consistency points. Inthe distributed case, unless there is a tightimport of the procedure, there is no way ofknowing at design time whether it will belocal or remote and, if it ends up remote, are-schedule must occur when the clientprocess suspends, which could allowother processes to enter the monitor andinvalidate the invariant.

This imposes a semantic change onour system compared with the standardModula-2. In our implementation, when amonitorised module calls another mod-

Software Engineering Journal September 1986 187

serial communications link

master

parallel bus

slave bus interface

dual portRAM microprocessor

privateRAM

slave

slave

Fig. 2 Hardware configuration

ule, the interrupt lock-out priority as-sociated with the caller is not transferredto the 'callee' unless the module isimported tightly. This single change in thesemantics of monitor operation is suffi-cient to cover all the effects of distributionand must be borne in mind by the pro-grammer. Note that if mutual exclusion isimplemented by semaphores then dis-tribution has no effect.

4.3 Scheduling

In Modula-2, processes are consideredto co-operate harmoniously to performthe task at hand, rather than competingindependently for shared resources.There are no redundant processes and allare needed for proper execution of theprogram. It is therefore often acceptedthat context switching need only occurwhen an explicitly programmed primitiveis used. Otherwise, if a process has someuseful work to do, it can be allowed tocontinue with it without loss of efficiency,since the processor is not idle. In a dis-tributed case this is not necessarily true.Consider a node that has both local pro-cesses, and agent processes that havebeen allocated procedure calls to per-form. It does not matter to that nodewhich of these processes is running, sinceit is not idling. It can matter to the clientnode, however, since it may have to idlewhile waiting for the results of the remotecall. It therefore seems more efficient togive agent processes priority over localprocesses when re-scheduling.

4.4 System-dependent facilities

The effects of 'WORD', 'ADDRESS' and'ADR' become unclear in a distributed

environment. If an exported procedurehas a parameter of type 'WORD' or'ARRAY OF WORD' then it is possible topass pointers to it, and this will not bedetected by the compiler. Hence pointerscould be transferred, illegally, betweennodes. However, since the programmerhas specified 'WORD' rather than anactual pointer type (or even 'ADDRESS') itcan be assumed that he will not know thetrue type of object he will get, and cannotassume it will be a pointer. Thus, even ona single node, it is invalid to later coercethat type to a pointer and de-reference it.Consequently we have not altered thissituation.

If a procedure is exported with type'ADDRESS' then it can be assumed thatpointers will be passed which may bede-referenced, and as such the importingmodule will be allocated to the same pro-cessor. Finally it should be noted that it isacceptable to use 'ADR' as normal since,for similar reasons to the above, if thevariable can be accessed then its addresswill be consistent for all the processes thatuse it.

5 Implementation

The system has been implemented asdescribed using the original compiler pro-duced by Wirth at the EidgenossischeTechnische Hochschule (ETH), Zurich,running under RT11 on a DEC PDP-11/23+. The target architecture can beseen in Fig. 2. It consists of a parallel busto which a number of slave processors areattached. These processors are referredto as slaves merely because they cannever gain bus mastership, which residespermanently with a single master pro-cessor. Each slave has a DEC single-chip

microprocessor (DCT 11-AA), 32 Kbytesof private RAM, and 2 Kbyte dual portedRAM which it shares with the master.

When a slave wishes to pass a messageto another slave it simply deposits themessage in its dual port RAM and inter-rupts the master. The master then, at aconvenient time, transfers the messageand interrupts the destination slave. Themaster therefore functions almostexclusively as a communications control-ler and interface to the next higher level(i.e. the system supervisor).

During linkage the linker detects thoseprocedure calls whose destination pro-cedure is to reside on a different node,and changes the code so that they arere-directed to the remote procedure callsystem. This program is itself coded inModula-2 and is tailored to suit ourspecific hardware configuration. The sys-tem is thus composed of three layers, withapplication level programs being sup-ported by the remote procedure call layer,which is in turn supported by the messagepassing layer.

5.1 Extensions

Animportantaimofourworkwillbethecollection of run time statistics from pro-grams and the use of this information dur-ing re-allocation. The amount of inter-processor communication, as well as theamount of true concurrency achieved,can be measured quite efficiently. Thisinformation can be used initially by theprogrammer as a yardstick with which tomeasure the performance of a givenallocation. Eventually we hope to pursueand extend some of the various methodsthat exist (Ref. 13) to define allocationsautomatically.

It should also be possible to adapt thesystem for ad hoc processor-memoryarchitectures. This will allow modules toshare variables and still reside on differentnodes providing there is enough com-mon memory accessible to both. Thesame is true of the heap which, if placed inshared memory, allows pointers to bepassed between nodes. Commonre-entrant modules can also be shared,although monitorised modules must stillbe accessed only by a single processor.

It is intended to report in due course onthe details of the implementation issuesthat have arisen, and present perform-ance data and experience gained in usingthe system.

6 Conclusions

This paper describes extensions and sup-port for Modula-2 to enable the languageto be used with distributed targets. Thenecessary run time support has beendefined as the remote procedure call,which maintains the same syntax and

188 Software Engineering Journal September 1986

semantics of local procedure calls. Theeffect on program correctness has beenexamined and found to be minimal, and asmall set of source language changesnecessary to support distribution hasbeen defined.

An important issue was found to be theallocation of software components toprocessing nodes, and global-level mod-ules were found to be the most suitableallocation unit. Almost all allocation-dependent information has been omittedform the source code, allowing programsto be coded independently of the alloca-tion. An allocator program is responsiblefor the interactive and iterative allocationof modules to nodes. This method shouldallow designers to experiment with vari-ous allocations and hardware configura-tions in order to optimise their software forthe task at hand.

Monitors and signals have beenadopted as the inter-process communi-cation method since, unlike channels orrendezvous type schemes, this schemekeeps the source code indpendent of thetarget architecture, allows more flexibleallocation, and is inherently moreefficient.

7 References

1 MITCHELL, I., WHITEHEAD, D. G., and PCJGH, A.: 'A multi-processor system for sensoryrobotic assembly', Sensor Review, 1983, April, pp. 94-96

2 WIRTH, N.: 'Programming in Modula-2' (Springer-Verlag, 1983), Third, Corrected Edition3 Reference manual for the Ada programming language. ANSI/MIL-STD-1815A-1983,

American National Standards Institute, Jan. 19834 BRINCH HANSEN, P.: The programming language Concurrent Pascal', IEEE Transactions

on Software Engineering, 1975, SE-1, (2), pp. 199-2075 HOARE, C. A. R.: 'Communicating sequential processes', Communications of ACM, 1978,

21,(8), pp. 667-6776 MOK, A. K. L.: 'Fundamental design problems of distributed systems for the hard real-time

environment'. Ph.D. Dissertation, MIT/LCS/TR-297, Massachusetts Institute of Technology,Cambridge, MA, GSA

7 LAMBERT, J. E., and HALSALL, F.: 'Program debugging and performance evaluation aids fora multi-microprocessor development system', Software & Microsystems, 1984, 3,(1), pp.2-10

8 COOK, R. P.: '*Mod — a language for distributed programming", IEEE Transactions onSoftware Engineering, 1980, SE-6, (6), pp. 563-571

9 BIRRELL, A. D., and NELSON, B. J.: 'Implementing remote procedure calls', ACM Trans-actions on Computer Systems, 1984, 2, (1), pp. 39-59

10 HOARE, C. A. R.: 'Monitors: an operating system structuring concept', Communications ofACM, 1974, 17, (10), pp. 549-557

11 WIRTH, N.: 'Schemes for multiprogramming and their implementation in Modula-2'. Techni-cal Report 59, Eidgenossische Technische Hochschule, Zurich, Switzerland, June 1984

12 LAMPSON, B. W., and REDELL, D. D.: 'Experience with processes and monitors in Mesa',Communications of ACM, 1980, 23, (2), pp. 105-117

13 MA, P. R., LEE, E. Y. S., and TSGCHIYA, M.: 'A task allocation model for distributed computingsystems', IEEE Transactions on Computers, 1982, C-31, (1), pp. 41-47

P. V. Mellor and D. G. Whitehead are with the Department of Electronic Engineering and J. M.Dubery is with the Department of Computer Science, University of Hull, Hull HC16 7RX, England.

Software Engineering Journal September 1986 189