.pn 1
.bp
.HD
.SZ 10 13
.ce
\fBAn Overview of the SR Language and Implementation\fR
.sp 2
.sh 1 "Introduction"
.pp
During the past two years we have redesigned and reimplemented
the SR (Synchronizing Resources) programming language.
Like its predecessor, SR[[0]] [Andr81, Andr82],
SR remains a language
for writing distributed programs.
Also, the main language constructs\(emresources and
operations\(emare conceptually the same.
However, based on our experience using SR[[0]] to write
numerous programs, including prototypes of the Saguaro
operating system [Andr87a], we have modified the language
in several ways.
In essence, SR is to SR[[0]] what Modula-2 is to Modula
[Wirt82, Wirt77]:
a second-generation language that incorporates refinements
based on experience with its predecessor.
.pp
The redesign of SR has been guided by three major concerns:
expressiveness, ease of use, and efficiency.
By expressiveness we mean that it should be possible to solve
distributed programming problems
in the most straightforward possible way.
This argues for having a flexible set of language mechanisms,
both for writing individual modules and for combining
modules to form a program.
Distributed programs are generally much more complex than
sequential programs.
Sequential programs usually have a hierarchical structure;
distributed programs often have a web-like structure in which
components interact more as equals than as master and slave.
Sequential programs usually contain a fixed number of components
since they execute on a fixed hardware configuration;
distributed programs often need to grow and shrink dynamically
in response to changing levels of user activity
and changing hardware configurations.
Sequential programs have a single thread of control;
distributed programs have multiple threads of control.
Thus, a distributed programming language necessarily
contains more mechanisms than a sequential
programming language.
.pp
One way to make a language expressive is to provide
a plethora of distinct mechanisms.
However, this conflicts with our second concern, ease of use.
As Hoare has so aptly observed, if programs are to
be reliable, the language they are written in must be simple
to understand and use [Hoar81].
The way we have resolved this tension between expressiveness
and simplicity is that SR provides a variety of mechanisms,
but they are based on only a few underlying concepts.
Moreover, these concepts are generalizations of those that
have been found useful in sequential programming,
and they are integrated with the sequential components
of SR so that similar things are expressed in similar ways.
The main components of SR programs are parameterized resources,
which generalize modules such as those in Modula-2.
Resources interact by means of operations, which generalize
procedures.
Operations are invoked by means of synchronous %call
or asynchronous %send.
Operations are implemented by procedure-like \fBproc\fRs
or by %in statements.
In different combinations, these mechanisms support
local and remote procedure call, dynamic process creation,
rendezvous, message passing, and semaphores\(em#all of which
we have found to be useful.
The concurrent and sequential components of SR are integrated
in numerous additional ways in an effort to make the language
easy to learn and understand and hence easy to use.
.pp
A further consequence of basing SR on a small number of
underlying concepts is good performance.
SR provides a greater variety of communication and
synchronization mechanisms than any other language,
yet each is as efficient as its counterpart in other languages.
We have also designed the language and implemented the
compiler and run-time support in concert,
revising the language when a construct
was found to have an implementation cost that outweighed its utility.
In addition, some of the expressiveness within the language
has been realized by ``opening up'' the implementation.
For example, the various mechanisms for invoking and servicing operations
are all variations on ways to enqueue and dequeue messages.
.pp
A detailed discussion of how these concerns
have influenced the evolution of SR is given in [Andr86].
This paper gives an overview of the language and its implementation.
We summarize the main language mechanisms,\**
.(f
\**The complete language is described in [Andr87b].
.)f
give examples of their use, describe the most interesting aspects of
the implementation, and give performance figures.
We also discuss the relation between SR and other
approaches to programming distributed systems.
