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
