Newsgroups: comp.sys.isis Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!ken From: ken@CS.Cornell.EDU (Ken Birman) Subject: Re: Isis tasking description Message-ID: <1991Apr11.145329.12745@cs.cornell.edu> Sender: news@cs.cornell.edu (USENET news user) Nntp-Posting-Host: gvax.cs.cornell.edu Organization: Cornell Univ. CS Dept, Ithaca NY 14853 References: <1991Apr10.151755.17399@aero.org> Date: Thu, 11 Apr 1991 14:53:29 GMT Lines: 77 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