*MOD(ID:879/mod001)Concurrent MOdula("StarMOD") Concurrent language combining the modules of Modula and the communications of Distributed Processes. Edited in the DYMOS system. Univ. of Wisconsin, Madison Places Related languages
References: in IEEE Transactions on Software Engineering 6(6) November 1980 view details in IEEE Transactions on Software Engineering 6(6) November 1980 view details *MOD borrows concepts from MODULA, SIMULA, distributed processes of Brinch Hansen, and ports of Balzer. *MOD provides network modules, processor modules, module types, and modules. Module types can be used to define extended types, as in SIMULA classes, and can also be used to replicate data and code for each use of the type. Modules define a closed lexical scope which can be overcome by explicit specification using the *MOD "define," "export," "import," or "pervasive" statements. A processor module in *MOD consists of one or more concurrent processes. Whereas references to a procedure cause an activation record to be created, referencing a process causes a new activation stack and state vector to be created. Communication between processes in different processors is carried out using messages. Messages can be handled by concurrent processes or be associated with a port which, in turn, is handled by a single active process. This port handler then handles the messages sequentially. A network module defines connections of the processors and data, procedures, and processes global to the network. A contribution of the language design is its unified treatment of procedure, process, and port. Also, the development employs kernels which allow a *MOD program to be executed in several different PDP-11 environments (bare machine kernel, simulation kernel, UNIX kernel). Experiments with the design were done using extensions to a MODULA compiler, but the author proposes a very high level language network environment and a compiler for several target machines. The article mainly presents an overview of the process, message, and port features of the language which are extensions of current concepts to distributed programming. The work described is continuing and evidently additional articles will appear in the future. in ACM Computing Reviews 22(10) October 1981 view details in ACM Computing Reviews 22(10) October 1981 view details in ACM Computing Reviews 22(10) October 1981 view details in ACM Computing Reviews 22(10) October 1981 view details The DYMOS Dynamic Modification System provides a fully integrated environment for software development and program updating for programs written in the StarMod programming language. StarMod is a concurrent programming language similar to Modula. The DYMOS environment consists of a command interpreter, a source-code management system, a StarMod compiler, a file editor, and a runtime environment. In DYMOS, a program is updated by replacing each individual procedure. Because StarMod supports the concepts of modules and abstract data types directly (as opposed to implementing them on top of a programming language like Pascal or C that does not support the concept directly), a program may also be updated at the level of a module. DYMOS also provides mechanisms to allow the specification of a procedure to change between versions as well as the implementation of static data local to a procedure. The programmer may also construct interface modules, which are similar to Hoare's monitors. Because DYMOS is an integrated system, the state of the source and object code of the program being executed/updated is maintained at all times. This allows selective recompilation of program units, which can be useful and efficient for software development. To update a program in this environment, the user must explicitly tell the updating system which procedures to update and under what set of conditions to update them. The conditions for updating a procedure in DYMOS consist of waiting for a specified set of procedures or modules to become idle, i.e. not being executed by any process. For example, the DYMOS command update A when X,Y,Z idle tells the updating system to update procedure A when procedures X, Y, and Z are idle. DYMOS has a number of problems that make it unsuitable for our environment. The StarMod language is not widely used, and furthermore, its syntax was modified to support dynamic program updating. We believe that altering a programming language's syntax to support updating (or anything else) invariably leads to portability problems. As noted earlier, because DYMOS is a fully integrated system, it provides a powerful software-development environment. In addition to maintaining both source and object code, it also keeps track of the program's syntax tree. This configuration has two important consequences. First, tools available under the host operating system must either be modified (assuming the source code is available) to manipulate the internal state information that DYMOS maintains, or they simply cannot be used. This is a problem if, for example, the DYMOS editor has a different user interface than the editor the programmer normally uses. Depriving a programmer of the tools he or she normally uses seriously impedes productivity. Second, DYMOS implicitly assumes that both the source and object code are available for its use. This assumption may be invalid in cases where the software provider and the software user are different. For example, a company providing proprietary software to a client whose code needs to be updated will, in general, not want to give the client the source code. Another potential problem with DYMOS is that each procedure must be updated by explicit action. Although the language constructs supplied for updating are quite expressive, an inexperienced user could accidentally update the wrong procedure at the wrong time with a simple typographical error when typing an update command. In some cases, it may even be possible to deadlock DYMOS. To avoid such errors, initiating a program update should be as simple and automated as possible for the person who must perform it. Because DYMOS updates multi-threaded StarMod programs, as opposed to distributed programs, some of its design assumptions differ from ours. Whenever a procedure is invoked, a complicated locking protocol must be executed to arbitrate access to the procedure. A penalty is paid for executing this protocol regardless of whether or not an update is in progress. More important, the locking protocol will not scale to a distributed system. Similarly, DYMOS only allows one update to be in progress at a time. In a distributed environment, this is unacceptable, since it may be advantageous or necessary to initiate a new update before previous updates have completed. In a system with many computers, the propagation time of an update (the time it takes for an update command to be received by all computers) may be quite large. Network problems such as faulty gateways and computer downtime for preventive maintenance or repair might also delay an update. Thus, waiting for an update to complete before starting a new one could become quite costly in many circumstances. in ACM Computing Reviews 22(10) October 1981 view details |