Prioritised dynamic communicating and mobile processes

Abstract

Continuing research on language design, compilation and kernel support for highly dynamic concurrent reactive systems is reported. The work extends the occam multiprocessing language, which is both sufficiently small to allow for easy experimentation and sufficiently powerful to yield results that are directly applicable to a wide range of industrial and commercial practice. Classical occam was designed for embedded systems and enforced a number of constraints, such as statically predetermined memory allocation and concurrency limits, that were relevant to that generation of application and hardware technology. This work removes most of these constraints and introduces a number of new facilities: explicit channel ends, channel bundles, mobile ends of channels and bundles, dynamic process creation, the extended rendezvous and process priorities. These significantly broaden occam's field of application and raise the level of concurrent system design directly supported. Concurrency overheads have been driven ever downwards, for example synchronising channel communication is now around 100 nanoseconds on an 800 MHz P3, and most operations have unit time cost. Finally, a proposal for secure mobile processes is made.

Communicating Mobile Processes

“…The first, described in [4], allow a single mobile process to support multiple implementations of process-types. That method of defining a mobile process allows the various implementations to share the state that persists between activations.…”

“…for dynamic mobile arrays [8] and mobile channel-types [9,10]. The 'fuller' version of mobile processes (described in [4]) requires the separately declared and persistent state to be initialised using a 'CONSTRUCT' block. This is called at the point of allocation, passing any parameters given.…”

“…For most applications of such a mobile, this would be undesirable. The mobile processes described in [4] This is adequate for many purposes, even though the syntax is slightly cumbersome. One of the reasons for defining mobile processes this way is so that state may be shared between several implementations -this 'integrate.suspend.0' has only one.…”

“…Our earlier model [4] for mobile processes requires them to terminate before they could be moved. This gives a simple and intuitive semantics for activation: and a relatively simple implementation.…”

“…Process types are as in [4] -just PROC header templates. A MOBILE process implementing such a type has an extra primitive it can invoke -'SUSPEND'.…”