scott@cs.rochester.edu (Michael Scott) (02/04/88)
The Psyche project at the University of Rochester is an attempt to
support truly general-purpose parallel computing. We define
"general-purpose" to mean that the systems software must enable the
applications programmer to do anything for which the underlying
hardware is physically well-suited. Our current work focusses on the
design of an operating system that will support the full range of
parallel programming models in a single programming environment.
Over the course of the past several years we have become increasingly
convinced that no single model of process state or style of communication
can be appropriate for all applications. Traditional approaches ranging
all the way from the most tightly-coupled shared-memory model to the
most loosely-coupled form of message passing have applications for
which they are conceptually attractive. Our goal is to allow each
application, and in fact each *part* of an application, to be written
under the model most appropriate for its own particular needs.
The Psyche user interface is based on passive data abstractions called
"realms." Each realm includes data and code. The code constitutes a
protocol for manipulating the data and for scheduling threads of
control. The intent is that the data should not be accessed except by
obeying the protocol.
To permit sharing of arbitrary realms at run time, Psyche arranges
for all realms to reside in what appears to be a single address space.
The portion of that address space that is actually visible to a thread of
control depends on the protection domain in which the thread executes.
Each protection domain is associated with a particular "root" realm, and
includes any other realms for which access rights have been demonstrated
to the kernel.
Depending on the degree of protection desired, an invocation of a realm
operation can be as fast as an ordinary procedure call or as slow as a
heavyweight process switch. Unless the *caller* insists on protection,
the protected and optimized varieties of invocation both look exactly
like local subroutine calls. The kernel implements protected invocations
by catching and interpreting page faults.
Multiple models of thread management are supported by moving most of
the responsibility for scheduling out of the kernel and into user
code. The kernel on each processor time slices between protection
domains that are active on its node (a given protection domain may be
active on multiple nodes). Upcalls are provided to user scheduling
routines whenever thread management might be required, including when
(1) an invocation into the domain has occurred (and a new thread
probably needs to be created), (2) an invocation out of the domain has
occurred (so the current thread is blocked and rescheduling is
appropriate), (3) an invocation has completed (so the calling thread
should be unblocked), (4) a user-specified timeout has expired, or (5)
a program fault has occurred (arithmetic, protection, etc.).
For hardware base, we are currently assuming a machine in which all or
most of the memory is accessible to every CPU. We are interested in
very-large scale parallelism, so we expect to pay a penalty for
accessingly non-local memory. We expect this so-called "NUMA problem"
(non-uniform memory access time) to be a major focus of our work. We
are investigating both bottom-up approaches based on memory access
statistics and top-down approaches based on semantic knowledge about
realms and protection domains.
We are in the early stages of implementation on a BBN Butterfly 1000
Parallel Processor. Two faculty members and 3 graduate students are
directly involved at present, with a perhaps a dozen others providing
regular critical input. An early technical report (UR CS TR 223) was
circulated fairly widely last year. A newer (and heavily revised)
version has been submitted for publication.
Contacts:
Michael L. Scott Thomas J. LeBlanc
scott@cs.rochester.edu leblanc@cs.rochester.edu
(716) 275-7745 (716) 275-5426
Department of Computer Science
University of Rochester
Rochester, NY 14627
--
Michael L. Scott
University of Rochester (716) 275-7745
scott@cs.rochester.edu scott%rochester@CSNET-RELAY
{decvax, allegra, cmcl2}!rochester!scott