Structure of the Multics Supervisor (Vyssotsky et al.)

 Kind of paper:

 Reading this paper gives one the impression of reading a product design
document.  It describes the combination ideas from earlier work (which may
or may not have been done by the authors) into a time-sharing,
multi-programming system.

 Motivation:

 The motivation for writing the paper is two-fold.  One, time-sharing and
multi-programming are hot topics of the time and they feel that discussing
the goals and issues of their project would benefit the computing community.
Two, they wanted to keep a paper trail.

 Their design motivation is to develop a large 'open-shop' computing
facility running on a multi-CPU GE 645.  They describe this in terms
analogous to a an electric power utility, where cost effective metered
service is provided on demand, to varying user needs, with some level of
(data and system) dependability, security, privacy and accounting.

 Summary:

 The system is provides a framework that hides hardware details for
interacting with specialized applications executed in the form of processes
by customers.  The system supports segmentation, paging and addressable
storage, with facilities provided for process to lock portions of core
memory and pre-fetch instructions and data.

 The authors introduce the concept of treating peripheral devices as files
so that programs can use either the TTY or a file for input.

 They describe the priority based scheduler which implements service denial,
rather than service degradation.  The system is setup to do symmetric
multi-processing and therefore each CPU picks a process to execute from a
ready queue.

 The system supports dynamic linking of segments (procedure/procedure and
procedure/data), and defines the concept of re-entrant code.

 They describe the systems support trap handling, and briefly touch on
protection against machine errors.

 Highlights, Key Points and Comments:

 This paper covers a lot of ground in the time-sharing and multi-processing
systems areas from a design perspective.   However, since this is a design
document it does not report on successes, failures and performance.

 They present a four part design methodology: borrow good ideas, discard
solutions that were previously found unsatisfactory, choose the most
satisfactory (or least unsatisfactory) and finally choose workable general
solutions.

 The discussion on the priority based scheduler which takes resource cost
into account is good.  The algorithm is straight forward and simple to
implement.  There is however, the possibility that lower priority process to
get starved.

 Dynamic linking is a good idea for a time-sharing system, especially if
many system facilities are provided in shared libraries.

 They give a good description of the expected hardware configuration.

 They list their coding guidelines.


Virtual Memory, Processes, and Sharing in MULTICS (Daley and Dennis, 1968) 
Jonathan Ledlie
 CS 736 March 3, 2000 

In MULTICS essentially everything is a segment 
and a process can have essentially as many segments as it wants.  The huge amount of 
flexibility given to the user (programmer) has two main costs: internal OS 
complexity and speed (many lookups to get at the piece of memory you wanted in the 
first place).  MULTICS’ indirection has many benefits, however, and they all link 
back to the original, stated, goals of the system.  The essentially unbounded 
number of segments points to their goal of having the amount of user memory be 
independent of the amount of real memory.  Their method of using names instead of 
addresses to refer to shared procedures greatly simplifies the user’s job in that 
names are easier than addresses, but especially the user does not need to manage 
this shared procedure’s memory (usually via overlays).  Their method of sharing 
functions through dynamic linking allows for situations not only like two users 
sharing the text segment of emacs, but also sharing library functions like 
printf(), allowing for greater overall sharing.  Their final goal is to protect 
these segments against unauthorized use; while their solution to this is not as 
clean or flexible as ACLs, for example, MULTICS does allow for restricting which 
segments are writeable and by whom.  As stated above, this indirection buys much for 
the user, but at what cost?  First, linking at run time can be slow.  Second, dividing 
their 36 bits into segment numbers and indices, pages and their indices, and 
offsets each with their own base registers is highly complex (we had to take out the 
Dinosaur book to see what was going on).  We felt that while MULTICS encompasses many 
good ideas, it violates Dijkstra’s idea of making your work overly ambitious but 
without too much grunt work.