abbott@aero.org (Russell J. Abbott) (04/10/91)
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.
ken@CS.Cornell.EDU (Ken Birman) (04/11/91)
In article <1991Apr10.151755.17399@aero.org> abbott@aero.org (Russell J. Abbott) writes: >..... I would appreciate any comments or corrections. It reads pretty well and is quite accurate. Some minor comments: >... 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. Using ISIS_TASK_EXIT() and ISIS_TASK_ENTER() one can potentially work with ISIS within a multi-threaded parallel processing environment. In fact, our Allegro LISP port operates this way. A task that has "left" ISIS will run concurrently with ISIS; only threads that are "inside" ISIS follow this FIFO rule. However, you must explicitly invoke these macros if you want true parallelism within ISIS, and you must be using a "native" threads package that supports parallelism or the macros will be compiled as no-ops. For example, ISIS under pthreads (a version of the Mach cthreads package) could support applications that use physical parallelism, despite the fact that ISIS itself is internally serialized. The redesign of ISIS should yield a system that is internally multithreaded, but it will be a while before we know how the interface will look. ..... >Interprocess broadcast requests are the only mechanism ISIS >provides for interprocess communication. There are no RPC's as such. No, this is incorrect. ISIS lets you multicast to a group, but you can also get the address of any of its members, or several of its members, and interact with them using RPC or multi-RPC calls. An ISIS RPC would be done using the broadcast system call, but to a group with only one member or to a process by its "address". Moreover, you can combine ISIS with non-ISIS RPC mechanisms, like SUN RPC, using isis_select from a task that watches the channels over which RPC's might arrive and than accepting them and replying using the standard RPC mechanism. We recommend that ISIS users do this if it makes more sense than to use ISIS broadcasts as an RPC interface. Whether it makes more sense will depend on many factors: the degree to which you like the ISIS interface (format strings as opposed to argument marshalling and "interface generators"), the performance needs of your application (native RPC is usually two or three times faster for small messages, although the difference shrinks as messages get larger), and the need to adhere to standards (under, say, OSF's DCE, a server pretty much HAS to accept RPC's in the standard OSF style, even if it wants to use ISIS internally to maintain its internal state). Thus, there is a significant choice here that the system architect needs to think carefully about. ... the rest of this section is fine, although when you say: >The lack of constraint on which user processes may belong to which process >groups can lead to inconsistent computations being performed... ... I am not completely clear on the type of inconsistency you are thinking of. I guess that you mean that ISIS won't do anything to make sure that the group members implement a correct algorithm, or (since they can be different programs) even implement the SAME algorithm. If so, this is quite right: ISIS only promises that the multicast primitives act in the ways advertised, and also that the various high level tools act as advertised. .... I would have expected a third section on "higher level" facilities, like the new resource manager, the new NEWS facility, and Meta. Many, if not most, ISIS users are drawn to the technology by these aspects of our system... Ken Birman -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428