sjc@cs.purdue.edu (Steve Chapin) (04/30/91)
After mailing out 93 copies of this in the last 3 days, I have decided
that it was worth posting after all. Of course, everyone who wants a
copy has it now, but...
this is in 2 parts, since it's > 64k.
Here is the compilation of answers I received to my query about
distributed programming environments.
Before I list them, I would like to publicly apologize to the people
in the Hermes group at IBM. I sent them a letter asking for an
interpretation of their User Agreement *after* I posted my message,
which was improper of me. I got a kind letter from Art Goldberg
(included below) explaining that anything I copyright would remain my
inetellectual property. Therefore, my objections to Herems were
groundless, and I could have avoided wrongfully besmirching IBM and
its employees by doing a little research first. Again, I apologize.
In a nutshell, there were 2 highly touted systems: Isis and PVM. A
few others were mentioned. All are listed below.
On to the responses:
===========================================================================
===========================================================================
From: vss@mathcs.emory.edu (V.S.Sunderam)
Message-Id: <9104221310.AA16398@emory.mathcs.emory.edu>
Subject: Re: Seeking Distributed Programming environments
Hi,
We have a distributed programming system that may suit your needs.
Of course, it is available for free, and enhancements and/or
modifications are encouraged and welcome. I'm enclosing a blurb
on our project - please feel free to contact me if you need
more information. BTW, who are you working with?
Regards
Vaidy Sunderam
Emory University
---------------------------------------------------------------------------
The PVM and HeNCE Projects
Description
PVM (Parallel Virtual Machine) is a software system that enables a
collection of heterogeneous computer systems to be used as a general pur-
pose concurrent computation resource. The individual machines may be mul-
tiprocessors, vector supercomputers, specialized graphics engines, or
scalar workstations, that are interconnected by a variety of networks. PVM
support software executes on each machine in a user-configurable pool, and
presents a unified, flexible, and powerful computational environment for
concurrent applications. User programs, written in C or Fortran, use a
library interface for access to PVM functions such as process management,
communication, synchronization, and miscellaneous administrative tasks. A
well-understood programming model, and ease of use are strengths of PVM;
the system provides a high level of transparency, and is built on effective
algorithms for networked based computing in a heterogeneous environment. An
interactive interface permits montioring, status checking, and tracing
application execution.
HeNCE (Heterogeneous Network Computing Environment) is a graphical
interface tool (under development) and methodology for using PVM. HeNCE
permits the specification of applications using a variant of directed acy-
clic graphs; individual nodes are associated with application modules and
executed under PVM. During or after execution, HeNCE displays an event-
ordered animation of application execution, enabling the visualization of
relative computational speeds, processor utilization, load imbalances, and
message traffic. A debugging component allows setting module-level break-
points, while a separate display shows the allocation of modules to PVM
host machines. HeNCE also supports the graphical configuration of PVM
hosts, assists in the generation of architecture-dependent object modules,
and contains provisions for task scheduling based on user supplied or
system-estimated cost matrices.
Applications and Environments
PVM and HeNCE are ideally suited for concurrent applications composed
of many interrelated but distinct sub-algorithms, although performance is
good even for traditional parallel applications. PVM and HeNCE are particu-
larly effective for heterogeneous applications that exploit specific
strengths of individual machines on a network. As a loosely coupled con-
current supercomputing environment, PVM is a viable scientific computing
platform, while the support tools and interactive graphical facilities are
valuable as an easy-to-use and convenient concurrent programming environ-
ment. The PVM and HeNCE systems have been used for molecular dynamics simu-
lations, superconductivity studies, distributed fractal computations,
matrix algorithms, and in the classroom as the basis for teaching con-
current computing.
Status and Availability
The beta release of the PVM system is now available and may be
obtained by sending electronic mail to netlib@ornl.gov with the message
"send index from pvm". This release contains a users guide and installation
notes; PVM has been tested on Sun3, Sun4, Cray, Alliant, IBM RS6000, TMC
CM2, Intel iPSC & RX, Sequent, and Stardent systems. The HeNCE interface
is expected to be available in August 1991.
Futures
The PVM and HeNCE projects are ongoing, and support at levels
appropriate to research projects may be reasonably expected. Over the next
several months, newer releases of PVM and HeNCE are planned, with enhance-
ments including fault tolerance, process migration, and shadow execution
facilities, toolkits for the graphical assembly of concurrent applications
>from skeleton templates, hierarchical visualization of application execu-
tion, and concurrent debugging facilities.
Contacts
For more information, or if you have specific questions or comments,
please send email to pvm@msr.epm.ornl.gov.
===========================================================================
===========================================================================
From: elias@theory.TN.CORNELL.EDU (Doug Elias)
Message-Id: <9104221814.AA22496@theory.TN.CORNELL.EDU>
Subject: Seeking Distributed Programming environments
Trollius, from the Cornell Theory Center, is available in source
form for $300 for non-profit institutions, and is being used
as the programming environment for loosely-coupled heterogeneous
multicomputers, including Suns, RS6000s, and basically any other
UNIX machine that uses Berkeley sockets for IPC. If you're
interested, you can download all the user-documentation from
theory via anonymous-ftp...login, then cd into transputer/docs --
there is a README file there, explaining what's what...
Let me know if there is anything else i can do,
doug
=======================
# ____ |Internet: elias@theory.tn.cornell.edu
#dr _|_)oug|USmail: Mgr., Adv. Comp. Res. Inst./Cornell Theory Center
# (_| | 704A TheoryCtrBldg/C.U./Ithaca/N.Y./14853-3801
# (_|__ |MaBelle: 607-254-8826 Fax: 607-254-8888
===========================================================================
===========================================================================
From: moulton@cs.utk.edu
Subject: Re: Seeking Distributed Programming environments
Organization: University of Tennessee, Knoxville - CS Department
In article <1991Apr22.122913.1660@hubcap.clemson.edu> you write:
>
>Greetings. I am seeking distributed programming systems for my PhD
>research. I am interested in systems that allow programming of a
>loosely-coupled heterogeneous multicomputer, and that are message
>based. I intend to implement task partitioning and scheduling
>algorithms that I am developing. If anyone knows of such a system
>that does not place restrictions upon its use, I'm very interested in
>hearing about it.
>
Currently under development:
PVM: Parallel Virtual Machine - a set of architecture independent
message passing subroutines. Includes calls for enrolling in
PVM system, reseiving and sending messages, broadcasts. Since binary
data may be sent, messages must be typed. However, binary data is
converted to appropriate format for destination machine.
PVM is available at netlib@ornl.gov. To get index of information
available, send the following message to netlib:
send index from pvm
To get sources (pvm library and pvmd daemon),
send pvm_shar from pvm.
HeNCE: Heterogeneous Network Computing Environment:
Consists of three pieces:
xnb: draw dags describing algorithm. Associates subroutines with
each node. When executed, HeNCE instrumented cod ewill automatically
schedule tasks on processorin in the virtual machine (PVM) based on the
user defined cost matrix and the program graph.
xnt: View trace of program run. Animation shows which tasks are running
where and when. Can be run either on trace file produced during run
or while run is taking place.
dag: Program that runs instumented program produced by xnb.
xnb write wrapper routines to instrument the user code. While HeNCE uses
PVM, all of the calls are encapsulated in the wrapper routines.
The above pieces may be conjoined in various fashions. This is
development software.
If you are interested, I will see if I can get you sources. Things are
still rather prototypical - I'd have to check with my advisor/boss
(Dr. Jack Dongarra) to see if he wants to expose the public. Off of the
top of my head, I'd say he would probably be happy to.
- Steve Moulton
--
Steve Moulton (moulton@cs.utk.edu) | I've always been more comfortable sinking
University of Tennessee, Knoxville | while clutching a good theory than swim-
Department of Computer Science | ming with an ugly fact. - David Mamet
===========================================================================
===========================================================================
From: carr%car@cs.utah.edu (Harold Carr)
Subject: Re: Seeking Distributed Programming environments
Organization: CSS
Ask Mark Swanson about Concurrent Scheme
swanson@cs.utah.edu
Harold
[ note: I did; his reply is below ]
===========================================================================
===========================================================================
From: walen@cs.ualberta.ca (Andrew E. Walenstein)
Subject: Re: Seeking Distributed Programming environments
Newsgroups: comp.parallel,comp.lang.misc,comp.lang.functional
In comp.parallel you write:
>Greetings. I am seeking distributed programming systems for my PhD
>research. I am interested in systems that allow programming of a
>loosely-coupled heterogeneous multicomputer, and that are message
>based. I intend to implement task partitioning and scheduling
>algorithms that I am developing. If anyone knows of such a system
>that does not place restrictions upon its use, I'm very interested in
>hearing about it.
>
>Oh, I'm just a lowly grad student whose professor has little to
>nothing in the way of funding, so the cheaper, the better.
>
>------------------------------------------------------------------------------
>Steve Chapin domain: sjc@cs.purdue.edu UUCP: ...!purdue!sjc
Well I'm also a lowly grad student, and I have just (like 6
hours ago) completed a survey paper on automated tools for MIMD
parallelization for a course on parallel programming. If you are
real desperate for a reference, I suppose I could email you the paper.
I warn you that I did it haphazardly (read "last-minute") so it is
not a `professional' survey. It contains some references to automated
tools and programming environment, and a reference to a _real_ survey
in a related field.
Andrew Walenstein
walen@cs.ualberta.ca
===========================================================================
===========================================================================
From: Ignacio.Trejos-Zelaya@prg.oxford.ac.uk
Subject: Re: Seeking Distributed Programming environments
Organization: Oxford University Computing Laboratory, UK
Dear Steve:
I don't know whether this helps you, but check a recent article on
comp.object announcing the availability of a portable implementation
of POOL2 (that generates C). I'm starting to read about POOL and it
looks nice, although I don't know whether it's suitable for your
pruposes.
Cheers,
Ignacio
===========================================================================
===========================================================================
From: ed@inmet.inmet.com (Ed Chianese)
Message-Id: <9104231527.AA24623@squid.inmet.com>
Subject: maybe isis
I read a notes about ISIS which is a can be used to program
distributed systems.
Its available free from cornel. I will give you a copy of the note.
/* Written 11:32 am Mar 18, 1991 by ken@cs.cornell.edu in squid:comp.parallel */
/* ---------- "Re: ISIS Toolkit" ---------- */
>Article 2371 in comp.parallel (moderated):
>From: rbs@aiai.ed.ac.uk (Robert Scott)
>Subject: ISIS of Cornell
>Keywords: distributed computing, networks, parallelism
>Message-ID: <1991Mar13.151443.13880@hubcap.clemson.edu>
>Date: 13 Mar 91 13:54:19 GMT
>Sender: fpst@hubcap.clemson.edu (Steve Stevenson)
>Reply-To: rbs@aipna.ed.ac.uk
>Organization: Department of AI, University of Edinburgh
>Lines: 16
>How do I get hold of the ISIS suite of Cornell?
>It allows one to setup distributed communications across
>networked UNIX machines, I'm told.
I hope this helps... It is a little stale by now, although not
in any extreme way. I don't normally follow this newsgroup, but
please feel free to email directly to me if you have any questions.
In very crude terms, ISIS is used a lot like the Linda system,
but where the emphasis in Linda is on anonymous communication, the
ISIS emphasis is on a more conventional message passing model, but
with rigorous semantics for "process groups" and group communication.
For example, this lets us solve problems in fault-tolerance, or to
subdivide a task using the current number of servers of some flavor
as a parameter, in a way that can support dynamic reconfiguration.
--- ISIS V2.1 blurb ---
This is to announce the availability of a public distribution of
the ISIS System, a toolkit for distributed and fault-tolerant
programming. The initial version of ISIS runs on UNIX on SUN,
DEC, GOULD, AUX and HP systems; ports to other UNIX-like
systems are planned for the future. No kernel changes are needed
to support ISIS; you just roll it in and should be able to use it
immediately. The current implementation of ISIS performs well in
networks of up to about 100-200 sites. Most users, however, run on
a smaller number of sites (16-32 is typical) and other sites connect
as "remote clients" that don't actually run ISIS directly. In this
mode many hundreds of ISIS users can be clustered around a smaller
set of ISIS "mother sites"; many users with large networks favor
such an architecture.
--- Who might find ISIS useful? ---
You will find ISIS useful if you are interested in developing
relatively sophisticated distributed programs under UNIX (eventu-
ally, other systems too). These include programs that distribute
computations over multiple processes, need fault-tolerance, coor-
dinate activities underway at several places in a network,
recover automatically from software and hardware crashes, and/or
dynamically reconfigure while maintaining some sort of distri-
buted correctness constraint at all times. ISIS is also useful
in building certain types of distributed real time systems.
Here are examples of problems to which ISIS has been applied:
o On the factory floor, we are working with an industrial
research group that is using ISIS to program decentralized
cell controllers. They need to arrive at a modular, expand-
able, fault-tolerant distributed system. ISIS makes it pos-
sible for them to build such a system without a huge invest-
ment of effort. (The ISIS group also working closely with
an automation standards consortium called ANSA, headed by
Andrew Herbert in Cambridge).
o As part of a network file system, we built an interface to
the UNIX NFS (we call ours "DECEIT") that supports tran-
sparent file replication and fault-tolerance. DECEIT
speaks NFS protocols but employs ISIS internally to maintain
a consistent distributed state. For most operations,
DECEIT performance is at worst 50-75% of that of a normal NFS
-- despite supporting file replication and fault-tolerance.
Interestingly, for many common operations, DECEIT substantially
outperforms NFS (!) and it is actually fairly hard to come up
with workloads that demonstate replication-related degradation.
o A parallel "make" program. Here, ISIS was used within a
control program that splits up large software recompilation
tasks and runs them on idle workstations, tolerating
failures and dynamically adapting if a workstation is
reclaimed by its owner.
o A system for monitoring and reacting to sensors scattered around
the network, in software or in hardware. This system, Meta, is
actually included as part of our ISIS V2.1 release. We are adding
a high level language to it now, Lomita, in which you can specify
reactive control rules or embed such rules into your C or Fortran
code, or whatever.
o In a hospital, we have looked at using ISIS to manage repli-
cated data and to coordinate activities that may span multi-
ple machines. The problem here is the need for absolute
correctness: if a doctor is to trust a network to carry out
orders that might impact on patient health, there is no room
for errors due to race conditions or failures. At the same
time, cost considerations argue for distributed systems that
can be expanded slowly in a fully decentralized manner.
ISIS addresses both of these issues: it makes it far easier
to build a reliable, correct, distributed system that will
manage replicated data and provide complex distributed
behaviors. And, ISIS is designed to scale well.
o For programming numerical algorithms. One group at Cornell
used ISIS to distribute matrix computations over large
numbers of workstations. They did this because the worksta-
tions were available, mostly idle, and added up to a tremen-
dous computational engine. Another group, at LANL, uses ISIS
in a parallel plasma physics application.
o In a graphics rendering application. Over an extended period,
a Cornell graphics group (not even in our department) has used
ISIS to build distributed rendering software for image
generation. They basically use a set of machines as a parallel
processor, with a server that farms out rendering tasks and
a variable set of slave computing units that join up when their
host machine is fairly idle and drop out if the owner comes
back to use the machine again. This is a nice load sharing
paradigm and makes for sexy demos too.
o In a wide-area seismic monitoring system (i.e. a system that
has both local-area networks and wide-area connections between
them), developed by a company called SAIC on a DARPA contract.
The system gathers seismic data remotely, preprocesses it, and
ships event descriptions to a free-standing analysis "hub", which
must run completely automatically (their people in San Diego don't like
to be phoned in the middle of the night to debug problems in Norway).
The hub may request data transfers and other complex computations,
raising a number of wide-area programming problems. In addition, the
hub system itself has a lot of programs in various languages and
just keeping it running can be a challenge.
o On brokerage and banking trading floors. Here, ISIS tends to be
an adjunct to a technology for distributing quotes, because the
special solutions for solving that specific problem are so fast
that it is hard for us to compete with them (we normally don't
have the freedom of specifying the hardware... many "ticker plant
vendors" wire the whole floor for you). However, to the extent
that these systems have problems requiring fault-tolerance, simple
database integration mechanisms, dynamic restart of services,
and in general need "reactive monitoring and control" mechanisms,
ISIS works well. And, with our newer versions of the ISIS protocols,
performance is actually good enough to handle distribution of
stock quotes or other information directly in ISIS, although
one has to be a bit careful in super performance intensive settings.
(The commercial ISIS release should compete well with the sorts of
commercial alternatives listed above on a performance basis, but
more than 10 trading groups are using ISIS V2.1 despite the fact that
it is definitely slower!).
The problems above are characterized by several features. First,
they would all be very difficult to solve using remote procedure
calls or transactions against some shared database. They have
complex, distributed correctness constraints on them: what hap-
pens at site "a" often requires a coordinated action at site "b"
to be correct. And, they do a lot of work in the application
program itself, so that the ISIS communication mechanism is not
the bottleneck.
If you have an application like this, or are interested in taking
on this kind of application, ISIS may be a big win for you.
Instead of investing resources in building an environment within
which to solve your application, using ISIS means that you can
tackle the application immediately, and get something working
much faster than if you start with RPC (remote procedure calls).
On the other hand, don't think of ISIS as competing with RPC or
database transactions. We are oriented towards online control and
coordination problems, fault-tolerance of main-memory databases, etc.
ISIS normally co-exists with other mechanisms, such as conventional
streams and RPC, databases, or whatever. The system is highly portable
and not very intrusive, and many of our users employ it to control some
form of old code running a computation they don't want to touch at
any price.
--- What ISIS does ---
The ISIS system has been under development for several years at
Cornell University. After an initial focus on transactional
"resilient objects", the emphasis shifted in 1986 to a toolkit
style of programming. This approach stresses distributed con-
sistency in applications that manage replicated data or that
require distributed actions to be taken in response to events
occurring in the system. An "event" could be a user request on a
distributed service, a change to the system configuration result-
ing from a process or site failure or recovery, a timeout, etc.
The ISIS toolkit uses a subroutine call style interface similar
to the interface to any conventional operating system. The pri-
mary difference, however, is that ISIS functions as a meta-
operating system. ISIS system calls result in actions that may
span multiple processes and machines in the network. Moreover,
ISIS provides a novel "virtual consistency" property to its
users. This property makes it easy to build software in which
currently executing processes behave in a coordinated way, main-
tain replicated data, or otherwise satisfy a system-wide correct-
ness property. Moreover, virtual synchrony makes even complex
operations look atomic, which generally implies that toolkit
functions will not interfere with one another. One can take
advantage of this to develop distributed ISIS software in a sim-
ple step-by-step style, starting with a non-distributed program,
then adding replicated data or backup processes for fault-
tolerance or higher availability, then extending the distributed
solution to support dynamic reconfiguration, etc. ISIS provides
a really unique style of distributed programming -- at least if
your distributed computing problems run up against the issues we
address. For such applications, the ISIS programming style is
both easy and intuitive.
ISIS is really intended for, and is good at, problems that draw
heavily on replication of data and coordination of actions by a
set of processes that know about one another's existence. For
example, in a factory, one might need to coordinate the actions
of a set of machine-controlled drills at a manufacturing cell.
Each drill would do its part of the overall work to be done,
using a coordinated scheduling policy that avoids collisions
between the drill heads, and with fault-tolerance mechanisms to
deal with bits breaking. ISIS is ideally suited to solving prob-
lems like this one. Similar problems arise in any distributed
setting, be it local-area network software for the office or a
CAD problem, or the automation of a critical care system in a
hospital.
ISIS is not intended for transactional database applications. If
this is what you need, you should obtain one of the many such
systems that are now available. On the other hand, ISIS would be
useful if your goal is to build a front-end in a setting that
needs databases. The point is that most database systems are
designed to avoid interference between simultaneously executing
processes. If your application also needs cooperation between
processes doing things concurrently at several places, you may
find this aspect hard to solve using just a database because
databases force the interactions to be done indirectly through
the shared data. ISIS is good for solving this kind of problem,
because it provides a direct way to replicate control informa-
tion, coordinate the actions of the front-end processes, and to
detect and react to failures.
ISIS itself runs as a user-domain program on UNIX systems sup-
porting the TCP/IP protocol suite. It currently is operational
on SUN, DEC, GOULD and HP versions of UNIX. Language interfaces
for C, C++, FORTRAN, and Common LISP (both Lucid and Allegro) are
included, and a new C-Prolog interface is being tested now. Recent
ports available in V2.1 include AUX for the Apple Mac. II, AIX on the
IBM RS/6000 and also the older PC/RT. A Cray UNICOS port is (still)
under development at LANL, and a DEC VMS port has being done by
ISIS Distributed Systems, Inc.
ISIS runs over Mach on anything that supports Mach but will probably
look a little unnatural to you if you use the Mach primitives. We
are planning a version of ISIS that would be more transparent in a
Mach context, but it will be some time before this becomes available.
Meanwhile, you can use ISIS but may find some aspects of the interface
inconsistent with the way that Mach does things.
The actual set of tools includes the following:
o High performance mechanisms supporting lightweight tasks in
UNIX, a simple message-passing facility, and a very simple
and uniform addressing mechanism. Users do not work
directly with things like ports, sockets, binding, connect-
ing, etc. ISIS handles all of this.
o A process "grouping" facility, which permits processes to
dynamically form and leave symbolically-named associations.
The system serializes changes to the membership of each
group: all members see the same sequence of changes. Groups
names can be used as a location-transparent address.
o A suite of broadcast protocols integrated with a group
addressing mechanism. This suite operates in a way that
makes it look as if all broadcasts are received "simultane-
ously" by all the members of a group, and are received in
the same "view" of group membership.
o Ways of obtaining distributed executions. When a request
arrives in a group, or a distributed event takes place, ISIS
supports any of a variety of execution styles, ranging from
a redundant computation to a coordinator-cohort computation
in which one process takes the requested actions while oth-
ers back it up, taking over if the coordinator fails.
o Replicated data with 1-copy consistency guarantees.
o Synchronization facilities, based on token passing or
read/write locks.
o Facilities for watching a for a process or site (computer)
to fail or recover, triggering execution of subroutines pro-
vided by the user when the watched-for event occurs. If
several members of a group watch for the same event, all
will see it at the same "time" with respect to arriving mes-
sages to the group and other events, such as group member-
ship changes.
o A facility for joining a group and atomically obtaining
copies of any variables or data structures that comprise its
"state" at the instant before the join takes place. The
programmer who designs a group can specify state information
in addition to the state automatically maintained by ISIS.
o Automatic restart of applications when a computer recovers
from a crash, including log-based recovery (if desired) for
cases when all representatives of a service fail simultane-
ously.
o Ways to build transactions or to deal with transactional
files and database systems external to ISIS. ISIS itself
doesn't know about files or transactions. However, as noted
above, this tool is pretty unsophisticated as transactional
tools go...
o Spooler/long-haul mechanism, for saving data to be sent to a
group next time it recovers, or for sending from one ISIS LAN
to another, physically remote one (e.g. from your Norway site
to your San Diego installation). Note: ISIS will not normally
run over communication links subject to frequent failures.
The long-haul interface, however, has no such restrictions.
o Network resource manager. This utility program is available
from ISIS Distributed Systems Inc. It sweeps idle machines into
a pool onto which it schedules programs upon request, picking the
least loaded machine of the appropriate architecture.
Everything in ISIS is fault-tolerant. Our programming manual has
been written in a tutorial style, and gives details on each of
these mechanisms. It includes examples of typical small ISIS
applications and how they can be solved. The distribution of the
system includes demos, such as the parallel make facility men-
tioned above; this large ISIS application program illustrates
many system features.
To summarize, ISIS provides a broad range of tools, including
some that require algorithms that would be very hard to support
in other systems or to implement by hand. Performance is quite
good: most tools require between 1/100 and 1/25 second to execute
on a SUN 3/60, although the actual numbers depend on how big
processes groups get, the speed of the network, the locations of
processes involved, etc. Overall, however, the system is really
quite fast when compared with, say, file access over the network.
For certain common operations a five to ten-fold performance
improvement is expected within two years, as we implement a col-
lection of optimizations. The system scales well with the size
of the network, and system overhead is largely independent of
network size. On a machine that is not participating in any ISIS
application, the overhead of having ISIS running is negligible.
In certain communication scenarios, ISIS performance can be quite
good. These involve streaming data within a single group or certain
client-server interaction patterns, and make use of a new BYPASS
communication protocol suite. Future ISIS development is likely
to stress extensions and optimizations at this level of the system.
In addition, a lot of effort is going into scaling the system
to larger environments.
--- You can get a copy of ISIS now ---
Version V2.1 of ISIS is now fully operational and is being made
available to the public. This version consists of a C implementations
for UNIX, and has been ported to AIX, SUN, UNIX, MACH, ULTRIX, Gould UNIX,
HP-UX, AUX and APOLLO UNIX (release 10.1). Performance is uniformly good.
A 400 page tutorial and sys- tem manual containing numerous programming
examples is also available. Online manual pages are also provided.
The remainder of this posting focuses on how to get ISIS, and how
to get the manual. Everything is free except bound copies of the
manual. Source is included, but the system is in the public
domain, and is released on condition that any ports to other sys-
tems or minor modifications remain in the public domain. The
manual is copyrighted by the project and is available in hard-
copy form or as a DVI file, with figures available for free on
request.
We have placed a compressed TAR images in the following places:
* cu-arpa.cs.cornell.edu (anonymous login, binary mode pub/ISISV21.TAR.Z)
* Doc: cu-arpa.cs.cornell.edu (pub/ISISV21-DOC.TAR.Z)
* uunet.uu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z)
* mcsun.eu.net (anonymous login, binary mode networks/ISIS/ISISV21.TAR.Z)
Also available are DVI and PS versions of our manual. Bound
copies will be available at $30 each. A package of figures to
glue into the DVI version will be provided free of charge.
A tape containing ISIS will be provided upon payment of a charge to
cover our costs in making the tape. Our resources are limited and
we do not wish to do much of this.
--- Copyright, restrictions ---
V2.1 of ISIS is subject to a restrictive copyright; basically, you can
use it without changing it in any way you like, but are not permitted
to develop "derivative versions" without discussing this with us.
V2.1 differs substantially from V1.3.1, which was released in the public
domain and remains available without any restrictions whatsoever.
On the other hand, whereas previous versions of ISIS required export
licenses to be sent to certain eastern-block countries, the present
version seems not to be subject to this restriction. Contact the US
Dept. of Commerce for details if you plan to export ISIS to a country
that might be subject to restrictions. Any place in Europe, Japan, etc.
should be fine and no license is required.
--- Commercial support ---
We are working with a local company, ISIS Distributed Systems
Inc., to provide support services for ISIS. This company will
prepare distributions and work to fix bugs. Support contracts
are available for an annual fee; without a contract, we will do
our best to be helpful but make no promises. Other services that
IDS plans to provide will include consulting on fault-tolerant
distributed systems design, instruction on how to work with ISIS,
bug identification and fixes, and contractual joint software
development projects. The company is also prepared to port ISIS
to other systems or other programming languages. Contact
"ids@isis.com" (or rcbc@cs.cornell.edu) for more information.
The commercial release of ISIS has been available since January 1991.
--- If you want ISIS V2.1, but have questions, let us know ---
Send mail to isis@cs.cornell.edu, subject "I want ISIS",
with electronic and physical mailing details. We will send you a
form for acknowledging agreement with the conditions for release
of the software and will later contact you with details on how to
actually copy the system off our machine to yours.
--- You can read more about ISIS if you like ---
The following papers and documents are available from Cornell.
We don't distribute papers by e-mail. Requests for papers should
be transmitted to "isis@cs.cornell.edu".
1. Exploiting replication. K. Birman and T. Joseph. This is a
preprint of a chapter that will appear in: Arctic 88, An
advanced course on operating systems, Tromso, Norway (July
1988). 50pp.
2. Reliable broadcast protocols. T. Joseph and K. Birman.
This is a preprint of a chapter that will appear in: Arctic
88, An advanced course on operating systems, Tromso, Norway
(July 1988). 30pp.
3. ISIS: A distributed programming environment. User's guide
and reference manual. K. Birman, T. Joseph, F. Schmuck.
Cornell University, March 1988. 275pp.
4. Exploiting virtual synchrony in distributed systems. K.
Birman and T. Joseph. Proc. 11th ACM Symposium on Operating
Systems Principles (SOSP), Nov. 1987. 12pp.
5. Reliable communication in an unreliable environment. K.
Birman and T. Joseph. ACM Transactions on Computer Systems,
Feb. 1987. 29pp.
6. Low cost management of replicated data in fault-tolerant
distributed systems. T. Joseph and K. Birman. ACM Transac-
tions on Computer Systems, Feb. 1986. 15pp.
7. Fast causal multicast. K. Birman, A. Schiper, P. Stephenson.
Dept. of Computer Science TR, May 1990.
8. Distributed application management. K. Marzullo, M. Wood, R.
Cooper, K. Birman. Dept. of Computer Science TR, June 1990.
We will be happy to provide reprints of these papers. Unless we
get an overwhelming number of requests, we plan no fees except
for the manual. We also maintain a mailing list for individuals
who would like to receive publications generated by the project
on an ongoing basis. The last two papers can be copied using FTP
>from cu-arpa.cs.cornell.edu.
If you want to learn about the virtual synchrony as an approach
to distributed computing, the best place to start is with refer-
ence [1]. If you want to learn more about the ISIS system, how-
ever, start with the manual. It has been written in a tutorial
style and should be easily accessible to anyone familiar with the
C programming language. References [7] and [8] are typical of our
recent publications (there are others -- contact Maureen Robinson
for details).
--
----------------------------------
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
--
=========================== MODERATOR ==============================
Steve Stevenson {steve,fpst}@hubcap.clemson.edu
Department of Computer Science, comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
===========================================================================
===========================================================================
From: swanson%teewinot@cs.utah.edu (Mark Swanson)
To: sjc
Subject: Re: Greetings
Well, that's a good question. Here's a (not-quite-randomly-chosen)
paragraph from my thesis:
Concurrent Scheme extends standard Scheme with the addition of four
types and their associated operations. It also imposes modifications
to the semantics of certain common operations. The following sections
will discuss the new types, operations, and restrictions; a reader
starting with a knowledge of standard Scheme should have a complete
understanding of CS by the end of this chapter. Several of the
concepts and mechanisms specified in this chapter: domains, delay
queues, delegation, and emigration (under the name {\bf forward}) are
derived from the Hybrid language\cite{Nierstrasz}. The new types
introduced will be {\it thread, domain, placeholder, and gateway};
each will be discussed in a major section but their interdependence
will necessitate some amount of forward-referencing.
Now that doesn't tell you much, right? It would probably be more
informative if you had the rest of the document. It'll become Tech.
Report number something or other as soon as I defend (next week).
Of more interest to you, perhaps, is what would be involed in modifying it.
It's built on top of Utah Lisp, which is a "kernel" we use to build Common
Lisp, Scheme, and Standard Lisp. So it's mostly Lisp-in-Lisp (CL syntax).
The concurrency stuff is written in UL, too. UL is a subset of CL, though
not as minimal as I would like.
The Scheme compiler is based on our UCL compiler and is written in UCL. So
you would need our complete suite to be able to change fundamentals. We'd
be happy to give you a copy, provided you understand that it's not a
product (i.e., we'd love to hear about bugs but can't guarantee when they'll
be fixed) and that you don't redistribute it, as we may decide to make a
product out of it and as we want to know who is using it and where it has
gone.
You need the compiler because the current Concurrent Scheme implementation
only supports compiled procedures. There is a read-eval-print loop, but
we don't handle interpreted functions very well (the explanation for this is
a long one unless you understand Concurrent Scheme quite well).
===========================================================================
===========================================================================
From: rfinch@locke.water.ca.gov (Ralph Finch)
Organization: Calif. Dept. of Water Resources, Sac.
Subject: Re: Seeking Distributed Programming environments
Consider ISIS:
ftp.cs.cornell.edu pub: 1272869 Sep 19 1990 ISISV21-DOC.TAR.Z
ftp.cs.cornell.edu pub: 1767509 Sep 19 1990 ISISV21.TAR.Z
--
Ralph Finch 916-445-0088
rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWR
===========================================================================
===========================================================================
From: adamb@cs.utk.edu
Subject: Re: Seeking Distributed Programming environments
Organization: University of Tennessee, Knoxville - CS Department
In article <1991Apr22.122913.1660@hubcap.clemson.edu> you write:
>
>Greetings. I am seeking distributed programming systems for my PhD
>research. I am interested in systems that allow programming of a
>loosely-coupled heterogeneous multicomputer, and that are message
>based. ... If anyone knows of such a system
>that does not place restrictions upon its use, I'm very interested in
>hearing about it. ...
>nothing in the way of funding, so the cheaper, the better.
Have we got a deal for you. We have a system called PVM that can be
used to write parallel programs to be distributed over a heterogeneous
network of machines. It's free and you can get it by sending email
to "netlib@ornl.gov" where the mail message contains the string:
"send index from pvm".
Here is a postscript document describing PVM:
I think this will be what you are looking for.
Adam
Dr. Adam Beguelin, adamb@cs.utk.edu UT 615-974-8295 ORNL 574-4158, Fax 974-8296
Department of Computer Science Mathematical Sciences Section
University of Tennessee Oak Ridge National Laboratory
Knoxville, TN 37996-1301 Oak Ridge, TN 37831-8083
%!PS-Adobe-1.0
%%Creator: eclipse:vss (V.S.Sunderam,216 Fishburne,7275926,2974135)
%%Title: stdin (ditroff)
%%CreationDate: Fri Mar 22 10:19:04 1991
%%EndComments
% Start of psdit.pro -- prolog for ditroff translator
% Copyright (c) 1985,1987 Adobe Systems Incorporated. All Rights Reserved.
% GOVERNMENT END USERS: See Notice file in TranScript library directory
% -- probably /usr/lib/ps/Notice
% RCS: $Header: psdit.pro,v 2.2 87/11/17 16:40:42 byron Rel $
/$DITroff 140 dict def $DITroff begin
%% Psfig additions
/DocumentInitState [ matrix currentmatrix currentlinewidth currentlinecap
currentlinejoin currentdash currentgray currentmiterlimit ] cvx def
/startFig {
/SavedState save def
userdict maxlength dict begin
currentpoint transform
DocumentInitState setmiterlimit setgray setdash setlinejoin setlinecap
setlinewidth setmatrix
itransform moveto
/ury exch def
/urx exch def
/lly exch def
/llx exch def
/y exch 72 mul resolution div def
/x exch 72 mul resolution div def
currentpoint /cy exch def /cx exch def
/sx x urx llx sub div def % scaling for x
/sy y ury lly sub div def % scaling for y
sx sy scale % scale by (sx,sy)
cx sx div llx sub
cy sy div ury sub translate
/DefFigCTM matrix currentmatrix def
/initmatrix {
DefFigCTM setmatrix
} def
/defaultmatrix {
DefFigCTM exch copy
} def
/initgraphics {
DocumentInitState setmiterlimit setgray setdash
setlinejoin setlinecap setlinewidth setmatrix
DefFigCTM setmatrix
} def
/showpage {
initgraphics
} def
} def
% Args are llx lly urx ury (in figure coordinates)
/clipFig {
currentpoint 6 2 roll
newpath 4 copy
4 2 roll moveto
6 -1 roll exch lineto
exch lineto
exch lineto
closepath clip
newpath
moveto
} def
% doclip, if called, will always be just after a `startfig'
/doclip { llx lly urx ury clipFig } def
/endFig {
end SavedState restore
} def
/globalstart {
% Push details about the enviornment on the stack.
fontnum fontsize fontslant fontheight firstpage
mh my resolution slotno currentpoint
pagesave restore gsave
} def
/globalend {
grestore moveto
/slotno exch def /resolution exch def /my exch def
/mh exch def /firstpage exch def /fontheight exch def
/fontslant exch def /fontsize exch def /fontnum exch def
F
/pagesave save def
} def
%% end XMOD additions
/fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def
/xi {0 72 11 mul translate 72 resolution div dup neg scale 0 0 moveto
/fontnum 1 def /fontsize 10 def /fontheight 10 def /fontslant 0 def F
/pagesave save def}def
/PB{save /psv exch def currentpoint translate
resolution 72 div dup neg scale 0 0 moveto}def
/PE{psv restore}def
/m1 matrix def /m2 matrix def /m3 matrix def /oldmat matrix def
/tan{dup sin exch cos div}bind def
/point{resolution 72 div mul}bind def
/dround {transform round exch round exch itransform}bind def
/xT{/devname exch def}def
/xr{/mh exch def /my exch def /resolution exch def}def
/xp{}def
/xs{docsave restore end}def
/xt{}def
/xf{/fontname exch def /slotno exch def fontnames slotno get fontname eq not
{fonts slotno fontname findfont put fontnames slotno fontname put}if}def
--
=========================== MODERATOR ==============================
Steve Stevenson {steve,fpst}@hubcap.clemson.edu
Department of Computer Science, comp.parallel
Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell