Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!usc!aero-c!abbott From: abbott@aero.org (Russell J. Abbott) Newsgroups: comp.sys.isis Subject: Isis tasking description Message-ID: <1991Apr10.151755.17399@aero.org> Date: 10 Apr 91 15:17:55 GMT Sender: news@aero.org Organization: The Aerospace Corporation, El Segundo, CA Lines: 87 For people here interested in ISIS, I have written a brief overview of how one might understand the ISIS tasking mechanism within the context of ISIS's overall goals and objectives. I would appreciate any comments or corrections. -- Russ Abbott@itro3.aero.org ====================================== ISIS provides tasking on two levels simultaneously. Lower Level: The ISIS lightweight tasking system ------------------------------------------------ At the lower level ISIS offers a form of lightweight tasking on a single processor. Within the standard ISIS programming style, a single user process (i.e., a C-language load-module), may include any number of lightweight task definitions. Syntactically, each one looks something like a subprogram. Since the entire collection of task definitions looks to Unix like a single user process, there is only one thread of control. ISIS provides a simple task scheduler so that these tasks may share this thread of control. Since this entire mechanism is relatively primitive, if ISIS is run on top of a system that has its own lightweight tasking mechanism, ISIS can be told to use that mechanism instead of its own. Within the ISIS scheduler, only one task runs at any time, and each task runs until it either completes or blocks (by calling for an ISIS system service). Tasks are run in FIFO order. Tasks may request the execution of other tasks either by requesting them explicitly or by setting conditions that trigger them. Such requests may be either standard (in which case they are queued) or urgent (in which case they are acted on immediately, leading to the suspension of the requesting task). Since all tasks in a process share a single (C-language) name space (and hence global variables), a blocked task may be affected by a task that runs while it is blocked. In addition, requests for task execution from outside a user process may be received and serviced. Such interprocess and interprocessor communication is, of course, ISIS's primary focus. The lightweight tasking mechanism is intended to serve it. Upper Level: The ISIS interprocess communication system ------------------------------------------------------- ISIS's primary service is virtual synchrony. Virtual synchrony is defined in terms of process groups. A process group may probably be most easily understood as representing a service for which the server is distributed over a network. Virtual synchrony ensures that every instance of such a server sees events in the ISIS world in the same order as every other instance. For example, imagine a distributed database that is partially (or fully) replicated. Requests to update and query the database are broadcast to the database process group and are received by all processes in that process group. ISIS guarantees that all such processes see these update and query requests in the same order and thus that the answers they provide are (potentially) consistent. Interprocess broadcast requests of this sort are the only mechanism ISIS provides for interprocess communication. There are no RPC's as such. As the database example suggests, each interprocess broadcast is directed toward a particular process group. Each broadcast also includes the name of a task to be performed. For example, a query request would be directed toward the database process group and would ask for the initiation of a query processing task. Such an interprocess request would be treated by the ISIS lightweight task scheduler (described above) as an external request for task initiation. Once a broadcast request is made, the requesting task my continue or it may wait for replies. As indicated, a process group consists of user processes, but process groups have identities independent of their member processes. User processes may join (and leave) process groups dynamically; they are not defined statically as belonging to any particular process group. In fact, a user process may be a member of a number of different process groups simultaneously. Thus process groups do not define process types; they do not constrain the class of processes that may belong to them; and they do not necessarily partition the set of user processes. This lack of constraint on which user processes may belong to which process groups can lead to inconsistent computations being performed. Any such inconsistency would be considered a programmer error rather than an ISIS error. ISIS provides the process group mechanism and leaves it to the programmer to use it for better or worse.