[comp.parallel] Announcing SR version 1.1

gmt@arizona.edu (Gregg Townsend) (07/28/89)

A revised implementation of the SR programming language is now available from
the University of Arizona by anonymous FTP or by mail.  The new version is a
little faster, a little more robust, and a lot more portable.  Some minor
changes and enhancements have also been made to the language itself.

SR (Synchronizing Resources) is designed for writing distributed programs.
The main language constructs are resources and operations.  Resources
encapsulate processes and variables they share; operations provide the primary
mechanism for process interaction.  SR provides a novel integration of the
mechanisms for invoking and servicing operations.  Consequently, all of local
and remote procedure call, rendezvous, message passing, dynamic process
creation, multicast, and semaphores are supported.  An overview of the
language and implementation appeared in the January, 1988, issue of TOPLAS
(ACM Transactions on Programming Languages and Systems 10,1, 51-86).

SR has been used at a number of universities and labs for course work
and research projects involving concurrent programming.  It has been
used in concurrent programming courses to reinforce concepts with
small programming projects and with larger projects such as replicated
databases, distributed simulations, and parts of distributed operating
systems such as file systems and command interpreters.  SR has also
been used as a tool in several masters theses and to implement larger
systems such as a system for mixed language programming, one for
distributed implementation of graph algorithms, experiments with load
balancing algorithms, and experiments with upcall program structures.

SR now runs on any of these machines:
    Vax  (BSD Unix, or Ultrix with gcc)
    Sun 2, Sun 3, or Sun 4
    Decstation 3100
    NeXT
    Hewlett Packard 9000 (series 300 and 800)
    Encore Multimax  (Umax)
An SR program runs on one or more networked machines of the same architecture.

SR is available by anonymous FTP from Arizona.EDU (128.196.128.118 or
192.12.69.1).  SR tar(1) files are available in the sr subdirectory;
be sure to transfer files in binary (image) mode.  The files are:

    sr.tar	The SR programming language, including source code,
		documentation, checkout programs, and examples.

    vs.tar	Extended verification suite, needed only if you're going to
		modify the system or port it to a new architecture.

The same files are also available in compress(1) form as sr.tar.Z and vs.tar.Z. 
If you pick up a copy of SR by FTP, please let us know by email to
"sr-project@Arizona.EDU".  This address can also be used for any questions or
comments.  Via uucp, you can reach us at uunet!arizona!sr-project.

SR is available by mail on 1/2" magnetic tape or 1/4" Sun cartridge.  For
details and an order blank, contact the SR project at the email address above;
or call (602) 621-2018; or send a letter to:

    SR Project
    Department of Computer Science
    University of Arizona
    Tucson, AZ  85721

An electronic mailing list is in place for discussing SR topics.  You can
join by sending your email address to "info-sr-request@Arizona.EDU".

James.Price.Salsman@cat.cmu.edu (07/31/89)

In article <6084@hubcap.clemson.edu> gmt@arizona.edu (Gregg Townsend) writes:

> SR (Synchronizing Resources) is designed for writing
> distributed programs.  The main language constructs are
> resources and operations.  Resources encapsulate processes
> and variables they share; operations provide the primary
> mechanism for process interaction.  SR provides a novel
> integration of the mechanisms for invoking and servicing
> operations.  Consequently, all of local and remote procedure
> call, rendezvous, message passing, dynamic process creation,
> multicast, and semaphores are supported.

Sounds good, but I have some questions:

- How well does it compile on to various types of parallel hardware?
- Why is the Multimax the only MIMD system that runs SR?
- Any plans for a port to a multiprocessor chip like the transputer
    or the i860?
- Could you compare & contrast SR with Ada's task model, Occam,
    and the BBN Butterfly's MultiScheme?
- Does it have any of Icon's string scanning and backtracking?
    [For those who don't know, Icon is from Arizona, too.]
- Could you elaborate on "An SR program runs on one or more networked
    machines of the same architecture."?
- What is meant by "synchronizing?"  To be more specific, is the term
    used in the asynch/sync sense or the synch/out-of-synch sense?
- Has the underlying paradigm been formalized as in Hoare's CSP?
- Can the denotational semantics be described in terms of temporal logic?

:James

Disclaimer:  The university and I do not think the same thoughts.
-- 

:James P. Salsman (jps@CAT.CMU.EDU)

gmt@arizona.edu (Gregg Townsend) (08/04/89)

In article <6119@hubcap.clemson.edu>, James.Price.Salsman@cat.cmu.edu
asks some questions about SR:

    - Could you elaborate on "An SR program runs on one or more networked
	machines of the same architecture."?

All SR programs execute using lightweight processes.  These may run in
multiple Unix processes, but there are always many more lightweight
processes than Unix processes.

Depending on how a particular program is structured, the lightweight
processes are distributed
    (1) within a single Unix process
or  (2) among multiple Unix processes on a single host
or  (3) among multiple processes on multiple hosts (using rsh(1))

The details are handled within SR;  the programmer just compiles the program
and runs "a.out".  However, the multiple machines must have a close enough
hardware and software environment to let them run the same executable file.

    - How well does it compile on to various types of parallel hardware?
    - Why is the Multimax the only MIMD system that runs SR?

Right now SR doesn't take any advantage of the parallelism except where
the multiple Unix processes of cases (2) or (3) run simultaneously.
We would like to address this in the future.  For now, the Multimax
is in the list simply because one happened to be handy.

    - Any plans for a port to a multiprocessor chip like the transputer
	or the i860?

No plans right now.

    - Does SR have any of Icon's string scanning and backtracking?
	[For those who don't know, Icon is from Arizona, too.]

Nope.  SR is in most respects fairly traditional, and has more of a
Pascal flavor than anything else.

[Thanks to Ron Olsson of UC Davis for answering the rest of these:]

    - Could you compare & contrast SR with Ada's task model, Occam,
	and the BBN Butterfly's MultiScheme?

SR's process and interprocess communication model is similar in some
ways to Ada and Occam, but is considerably more flexible.  The Jan 88
TOPLAS paper gives the details.

    - What is meant by "synchronizing?"  To be more specific, is the term
	used in the asynch/sync sense or the synch/out-of-synch sense?

The former.

    - Has the underlying paradigm been formalized as in Hoare's CSP?

No.

    - Can the denotational semantics be described in terms of temporal logic?

Not sure exactly what you mean here.  Some work on using continuations
to express concurrency in denotational semantics has appeared recently
(maybe in POPL?).  However, its relationship, if any, to temporal
logic is not at all clear.