Implementation of task types in distributed Ada

With the decline in the price of microcomputer hardware and the growth of high speed local area networks, distributed computation is mnking inroads into a.ll forms of computing. To be able to design and implement an effective distributed system it is essential to have a language that supports distribution. Ada is one of the few languages whose definition explicitly admits distribution. There have been various attempts to distribute Ada, [3],[2],[4]?[1], [S], to cite a few, but none of them explain in detail how to implement the distribution of the various Ada units. In [7,6] it is recommended that library packages and subprograms be the units that may be distributed. Distribution of these units implies that it must be possible to remotely access data objects, subprograms, tasks, data types and task types declared in library packages. Techniques for managing aJ1 but the hast of these for loosely coupled systems are reported in [6]. In this paper we outline techniques to deal with remote t&ask types in a specific implementation using a pre-translator approach. We are developing a pre-translator that translates a single Ada progmm into a set of Ada programs, one per site, that communicate with each other through agents and a mailbox system that are added by the pre-translator. These individual programs are then compiled usin, u an e.xisting vdidated Ada compiler. The binding of a program se_gment to a logical site is specified by a pragma named SITE. The binding of logical sites to actual processors is deferred until load time. The greatest difficulties that occur are with remote use of task types. One can require that objects created from task types be placed on the site of the type decluration or on the site of the object declaration or allocation. We adopt the second distribution approach. The task, being an active entity, will affect the scheduling of the other tasks in the package in which the task is declared or allocated and hence scheduling at the site of that package. Furthermore, we assume the programmer had some load balance in mind when assigning task objects to various packages on various sites; the translation system should respect that. There are then three main issues in implementing task types. 1) Task objects can be passed as arguments to subprograms or tasks on other sites. The remote site should be able to identify the site of the task. 2) If the task body is placed on sites other than the one on which the package declarin, e it resides, objects normally hidden in the package body enclosing the task body definition must now be made accessible remotely. 3) The package body in which the body of the task type is declared, could make objects from other packages visible to the body of the t&ask type. As these packages could be remote, the body of a task type may access objects whose localness or remoteness depends on the site where the instance of the task type is elaborated.