Cours Modula-P on distributed systems, tutoriel & guide de travaux pratiques en pdf.

Replicators

The components of a PAR or ALT statement may be replicated. A replicated process component has the form:
[ident : lower bound TO upper bound] p
(upper bound – lower bound + 1) processes are started all executing p in parallel. Each pro-cess knows its value of ident, that is each pro-cess gets a unique identification value in the range [lower bound .. upper bound], which is accessed using ident.
A replicated alternative has the form:
[ident : lower bound TO upper bound] guard : stmts
(upper bound – lower bound + 1) alternatives are set up, waiting for the guards.
Constraints for the use of the replicator variable:
• The type of ident must be ordinal.
• The type of lower bound and upper bound must be assign compatible to that of ident.
• The control variable ident is not allowed to be a component of a structured variable, nor may be imported or parameter of a procedure.
• The control variable may be used only like a constant.
If (upper bound – lower bound + 1) ≤ 0 then no component (process or alternative) is created.
The general form of a replicator is
replicator = « [ » ident « : » lwb « TO » upb « ] ».
lwb = expression.
upb = expression.

Modula-P on distributed systems

The main design problem of a language for pro-gramming distributed systems based on Modula-2, comes from the fact, that Modula-2 has a concept for the formulation of abstract data types with memory, which make use of global (level 0) variables. This feature is expressed in Modula-2 by the module con-cept. Allowing concurrent processes, the variable access problem arises, i.e. what should be done if several processes want to write a variable at a time? Another question comes from the fact that processes may run on different processors, which don’t share a common memory. The question here is, on which processor are the global variables allocated, and how is the access realized?
The answer of CSP is not favouring shared stor-age, because it is another way for process interac-tion.
Two answers are possible for this problems, first forbid all global variables and second invent lan-
guage constructs which make the use of global variables possible and save. The first answer is very restrictive and the resulting language is neither a superset of Modula-2 nor should be called Modula-xy.
Our solution is to allow shared memory, only if father and son process run on the same processor. Syntactically this is expressed by writing as compo-nent process of a PAR statement just a sequence of statements. This son process is named a local pro-cess. The variable access synchronization problem in this case is left to the programmer.
If the process needs abstract data types with mem-ory and no shared memory is desired, the process module encapsulation mechanism is provided. A process declared in a process module is called a global process. A global process may define global variables, but one global process can not access the variables of another global process. As a conse-quence, global processes may run on different pro-cessors, without the problems mentioned above.
Both process kinds are specified by the syntax, but it must not be specified by the program on which processor the processes are executed.
Our solution allows the runtime system to dis-tribute global processes over different processors and ensure that processes using common storage are running on the same processor. An an auto-matic mapping of channels to hardware connections is possible too. Hence the design goals of preserving the programmer from thinking about the allocation of hardware resources and the independence of the program text from the network architecture are ful-filled.

Process declaration

There are two ways (as a local or global process) to specify the actions a process should execute.

Local processes

Local processes are specified by writing the state-ment sequence the process should execute as a com-ponent of the PAR statement. This implies that this process has access to objects from its father process, which means that shared storage is allowed. No syn-chronisation is done by the system if several parallel executed local processes access the same variable.
A local process runs on the same processor as the father process, which executes the PAR statement.
A local process is not allowed to contain a RE-TURN statement nor an EXIT statement, which is related to a LOOP outside of that local process.

Process modules and global processes

The encapsulation in a process module is something like a Modula-2 program module. As a program module a process module may import other mod-ules, and only the name of the program or process is visible outside. While a program module is invoked form the operating system level, a global process is initiated, when the PAR statement containing a call to this process is executed. Like starting a program module causes the bodies of all imported modules to be executed, similarly for the modules imported by that process module is done each time the global process is invoked. And again, like each running program module has its own memory (from the op-erating system view), a global process has its own memory as long it is active. As concurrently exe-cuted Modula programs have no access to variables of each other, a global process has no access to vari-ables of another global process. Unlike a program module a process module may be called with pa-rameters. The formal parameters of a global process may only be value parameters. The types used in the formal parameter list are either predefined types or are implicit imported, hence this type identifier must be qualified. These qualified identifiers are known only inside this parameter list. The formal parame-ters are declared at level 0.