[comp.lang.ada] Ada using the Internet for multi-tasking

cml8@robin.cs.uofs.edu (Chris M. Little) (03/20/91)

I was discussing with a friend the possibility of a single Ada program spawning
its tasks over many hosts on the Internet or any other network or subnet.  We
have about 30 Sun 4 Workstations in our department.  I have an account on all
of them.  If I had a huge Ada program which utilized multi-tasking, I would
like for the workload to be shared by all of them, and not just one.  Has
anyone else entertained this concept and/or does anyone know of an Ada package
that might support this?  Any insight on the issue would be welcome.




-- 
Chris Little, Graduate Asstistant	-     CML8@JAGUAR.UOFS.EDU	(VMS)
Department of Computing Sciences	-     CML8@SCRANTON.BITNET	(VMS)
University of Scranton, Pennsylvania.	-     CML8@ROBIN.CS.UOFS.EDU    (UNIX)

rharwood@east.pima.edu (03/23/91)

In article <366@platypus.uofs.edu>, cml8@robin.cs.uofs.edu (Chris M. Little) 
writes:
> I was discussing with a friend the possibility of a single Ada program spawning
> its tasks over many hosts on the Internet or any other network or subnet.  We
> have about 30 Sun 4 Workstations in our department.  I have an account on all
> of them.  If I had a huge Ada program which utilized multi-tasking, I would
> like for the workload to be shared by all of them, and not just one.  Has
> anyone else entertained this concept and/or does anyone know of an Ada package
> that might support this?  Any insight on the issue would be welcome.

First, your system manager should violently object to such a possibility, if it
existed! <grin>

But I am not aware of any current Ada compiler that allows for a single program
to be written which "multi-tasks/multi-processes" over multiple processors.  I
worked on a radar warning receiver which utilized 3 80186s running somewhat
similar functions... but we had to take the approach of building a messaging
system interface between the processors (we actually used FIFOs-on-a-chip) with
special message structures for communicating "work tasks" and other info.  As a
Mac/VAX user, I'm not familiar with the UNIX interprocess communication
capability other than to say I know it exists... hopefully your compiler vendor
has provided a package with the interface calls "pre-coded".

Ray Harwood            |PO Box 18324        |Internet: rharwood@east.pima.edu
Owner, Data Basix      |Tucson, AZ 85731    |AppleLink: DATA.BASIX
Associate Faculty,     |Voice: (602)721-1988|CompuServe: 76645,1370
 Pima Community College|FAX:   (602)721-7240|Opinions: My own

madmats@elcgl.epfl.ch (03/25/91)

In article <366@platypus.uofs.edu>, cml8@robin.cs.uofs.edu (Chris M. Little) writes:
> 
> I was discussing with a friend the possibility of a single Ada program spawning
> its tasks over many hosts on the Internet or any other network or subnet.  We
> have about 30 Sun 4 Workstations in our department.  I have an account on all
> of them.  If I had a huge Ada program which utilized multi-tasking, I would
> like for the workload to be shared by all of them, and not just one.  Has
> anyone else entertained this concept and/or does anyone know of an Ada package
> that might support this?  Any insight on the issue would be welcome.
> 

I have developped an Ada package called Distributor that enables execution of
distributed Ada applications on a DECnet network. I intend to port this package
to UNIX/internet by the end of this year.

Of course, several instances of an Ada program have to run and make up a
distributed application (actually distributing tasks over such a network would
not be feasible because of data shared by tasks and access types among others.
Moreover, it would require modifying an Ada compiler or run time system).

The communication is based on message passing between processes, but more
elaborate communication protocols may be built by extending the package.

If anyone is interested, I have a draft of the paper that I intend to publish
some day on this topic, and I would be glad to have anyone's comments.


Mats Weber
Swiss Federal Institute of Technology
EPFL DI LGL
1015 Lausanne
Switzerland

E-mail : madmats@elcgl.epfl.ch
phone  : +41 21 693 52 92
fax    : +41 21 693 39 09

johndoe@inmet.UUCP (johndoe ) (03/27/91)

In article <1991Mar25.150213.1@elcgl.epfl.ch> madmats@elcgl.epfl.ch writes:
>In article <366@platypus.uofs.edu>, cml8@robin.cs.uofs.edu (Chris M. Little) writes:
>Of course, several instances of an Ada program have to run and make up a
>distributed application (actually distributing tasks over such a network would
>not be feasible because of data shared by tasks and access types among others.
>Moreover, it would require modifying an Ada compiler or run time system).

There is the possibility of using CAIS-A (Common APSE Interface Set)
technology of doing distributed computing over a single network.
Currently, the CAIS-A distributed implementation is a set of interfaces
that allows access to the common database through a main server
coordinating activity and a set of local_servers - one per machine.  For
a set of client Ada programs running on different machines, communication
is accomplished via CAIS-A interfaces for I/O and database access.  The
client programs would refer to one another, as well as to the communication
gateway and channels, with entities associated with the database.  This
requires no changes to a compiler or run-time system for a networked
Ada application.

Of course, at this point, it would have to be a network of Sun3
computers, since the only currently available distribution of a CAIS-A
implementation is for targeted to Sun3 architecture.  And for the time
being, you couldn't compile it, because the only supported compiler is
made by Systeam, who are now a subsidiary of Alsys, and who don't really
have a compiler product per se.  However, this should be changing in the
near future with a VMS version of a CAIS-A allowing distributed
processing, and support for the Telesoft compiler on Sun3, and the
Systeam and DEC compilers for the VAX.

For more information about CAIS-A, contact me (johndoe@inmet.inmet.com), or
Barry Siegel of NOSC (siegel@tecr.nosc.mil).