NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/isis/237

Text File | 1992-09-08 | 6.0 KB | 128 lines

Newsgroups: comp.sys.isis
Path: sparky!uunet!usc!rpi!batcomputer!cornell!glade
From: [e-mail] (Bradford Glade)
Subject: Lightweight Process Groups
Message-ID: <[e-mail]>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Mon, 7 Sep 1992 17:04:27 GMT
Lines: 118

  >Newsgroups: comp.sys.isis
  >From: [e-mail] (Ken Birman)
  >Subject: Re: ANSA, ISA and ISIS.
  >
  >In article <[e-mail]> [e-mail] (Barry Kitson) writes:
  >>Just found another interesting snippit in the Isis Ref. Man.
  >>
  >>    What is the current status of ISIS wrt ISA and the
  >>ANSA architecture?
  >>
  >
  >I really like the ISA/ANSA work, but our ties with that organization
  >are less active lately.  I tend to see ToolTalk and NewWave as the
  >commercial realizations of ANSA (aka OMG) and we have been thinking
  >about how to integrate ISIS better into this type of OO environment.
  >
  >We have a paper, with Olof Hagsand ([e-mail]) and Holger Herzog
  >(Siemens) on issues raised by this problem.  The result of this study
  >was a prototype OO presentation of ISIS for C++ users, and also a lot
  >of insight into the role that lightweight groups will play in future
  >versions of ISIS.  Brad Glade is now working on this problem at the
  >level of operating systems interfaces; the plan is to then work up to
  >higher level interfaces and finally focus on integration with the OO
  >environments sometime next year.
  >
  >Brad -- could you say something about lightweight groups?  People probably
  >won't know what this is about...
  >

Sure ...

Lightweight groups in Horus (aka ISIS++) are designed to address the
performance problems encountered by ISIS applications programmers that
use lots of highly overlapping groups.  Casual use of the process
group paradigm in ISIS applications can incur unnecessary overhead
when maintaining causality and failure atomicity obligations across
groups.  When a failure of a process occurs, ISIS must flush active
(unstable) messages for each of the groups to which that process
belongs, and deliver a new view of the group's membership.

The impact of this protocol when taken alone is fairly small
(essentially forcing synchrony at all members), but when combined with
other concurrent invocations of the protocol, it can have a large
impact on the system, due to the large number of messages being sent.
Unfortunately, this scenario is becoming more common.  The ISIS
process group paradigm is being used to represent more and more
lightweight objects in distributed applications.  For example, the
original design of the Deceit file system used an ISIS process group
to represent a collection of servers maintaining replicas of a file.
Each active file in the file system had its own corresponding process
group.  This initial design suffered performance problems due to the
interaction of the ISIS protocols when communication switched between
groups and when failures occurred.  The author (Alex Siegel) then
underwent a redesign of the system to reduce the number of process
groups used in the system and substantially improved the performance.

The lightweight process group mechanism in Horus will provide an
interface similar to the process group interface present in ISIS
today. However, the system will detach the interface from the
communication protocols, allowing multiple lightweight process groups
to share the same process group infrastructure.  The desired effect
being to retain the process group paradigm for use with lighter weight
objects yet provide good performance, avoiding overhead due to
competing process group interactions where possible.  The system will
also act as an environment for looking at different process group
semantics, this aspect though is more interesting from a research
point of view than from the user base.  In addition the interface will
allow for pipelining of distributed operations in a manner similar to
the asynchronous I/O operations provided by several flavors of UNIX.
This will retain the strong oredering guarantees provided by ISIS and
allow for the clean notification of error conditions, and synchronous
results.

As Ken mentioned the LWG mechanism lies at the OS interface (the Horus
kernel, MUTS, can be dropped into the OS's system space for efficiency)
and will be used by the tools built on top of the system.  It will
provide the foundation for object oriented interfaces and tools built in
the user level libraries.

The following papers are relevant to lightweight process groups and
the design of Horus.

  "Lightweight Process Groups" by Bradford Glade, Kenneth Birman,
  Robert Cooper, and Robbert van Renesse to appear in the proceedings
  for the OpenForum '92 Technical Conference in Utrecht, Holland in
  November.

  "Reliable Multicast between Microkernels" by Robbert van Renesse,
  Kenneth Birman, Robert Cooper, Bradford Glade, and Patrick
  Stephenson in the Proceedings of the USENIX workshop on
  Micro-Kernels and Other Kernel Architectures.

  "A RISC Approach to Process Groups" by Robbert van Renesse, Robert
  Cooper, Bradford Glade, and Patrick Stephenson in the Proceedings of
  the Fifth ACM SIGOPS European Workshop.

These papers may be obtained via anonymous FTP from ftp.cs.cornell.edu
(128.84.218.75).  They can be found in the directory /pub/horus under
the names lwg.ps, micro.ps, and sigops.ps respectively.

I would like to hear from people who have ideas for new tools that
they would like to see and who have requests for better support of
object orientation, etc.  This is your opportunity to shape the design
of the user interfaces provided in this new generation of ISIS.
Please feel free to discuss any aspects of the ISIS toolkit that
really like, really hate, or would really like to see.  Email to me
can be sent to [e-mail], or feel free to post here.

Thanks, I look forward to your input.

-Brad.


--
Bradford B. Glade             |  [e-mail]
Dept. of Computer Science     |  Tel. [phone] (Office)
314 Upson Hall Cornell Univ.  |  FAX  [phone] (CS Dept.)
Ithaca, NY 14853              |