From: Cliff Schmidt (cliff_at_bea.com)
Date: Sun Jan 11 2004 - 23:21:53 PST
The Dennis/Van Horn paper covers a lot of detail around handling parallel
processing, object naming, and protection in a "multiprogrammed computer
system (MCS)".
After a summary of the advantages of a properly managed MCS (including
preventing interference, maximizing resource availability, and elimination
of duplication of procedures and data), the authors define a set of
terminology. The number of terms introduced is a little overwhelming
without yet getting into the meat of the paper, but most of the
definitions are necessary are necessary. I wonder if the "Concepts and
Terminology" section should have been restructured into two shorter sections
on "Definitions" and "Lists of Capabilities", since many of the terms are
used to describe the core concept of C-lists. It's interesting to read the
description of the "ownership indicator", which is disputed in the Wulf, et
al. paper on HYDRA. I liked the very simple definition of a process: "an
abstract entity which moves through the instructions of a procedure as the
procedure is executed by a processor". The "state word" was worst-named
definition for something that is supposed to represent the set of
information that must be loaded into a processor to continue execution of
a process (at the very least it should have been called "state words", since
there are several different words that make up the state). The definition
of a "computation" almost sounded like a set of processes that make up an
application.
The "supervisor" looked to me like something that would be called a "kernel"
about four years later in a paper by Brinch-Hansen. The supervisor handles
allocation, scheduling, accounting, and controlling resources through the
use of the meta-instructions described later in the paper.
The description of lockout is pretty straight-forward, although I had to
wonder if the following statement was somewhat naive: "In practice the
execution time of a typical update sequence is quite small and the chance
that a process will hang up on a lock instruction will be very low.". I
would expect that the chances of a hanging process will increase with the
number of concurrent processes; were the authors assuming a limit to the
maximum number of concurrent processes?
The most interesting part of the "Inferior Spheres of Protection" section
was the emphasis on enabling the scenario where one computation is able
to debug another with different capabilities. The authors even account
for a breakpoint instruction to assist in debugging. Also interesting to
read early ideas for exception handling with the w parameter of the "create
sphere" instruction indicating the "return point for exceptional
conditions".
I found the Directories and Naming discussion reminding me of similar
issues that have had to be solved with the development of XML and XML
Namespaces. The need to allow the freedom for each user to create a
universally unique name based on a namespace that is unique to the user
is similar to the Web's Universal Resource Identifiers, often designated
by an individual's or company's registered domain name. XML also allows
for default namespaces to allow local names to represent the fully
qualified name, as well as abbreviations for multiple namespaces to make
references more readable (not to conserve space as mentioned by the
authors). It was historically interesting to read about hierarchical
directories (suggested by Daley and Neuman in 1965) and root directories.
Also, interesting that the directory structure is really a graph, not a
tree, since file references can exist in multiple directories. Multiple
paths can exist to the same file, but only one path is the normative one
designated by a consistent line of ownership relations.
This archive was generated by hypermail 2.1.6 : Sun Jan 11 2004 - 23:21:57 PST