% to get hardcopy of this lecture, you need the following files (plus the
% normal latex and tex base directories):
%     lecture.tex:     latex source file
%     macros.tex:      figure macros
%     psfig.tex:       postscript figure (psfig) macro definition
%     sort.idraw:      first figure, created with idraw
%     security.idraw:  second figure, created with idraw
%     proof.idraw:     third figure, created with idraw
%     pocs-header.sty: Principles of Computer Systems lecture latex header
%
% run the following programs:
% latex lecture
%   -> Creates lecture.dvi, plus latex intermediate files
% latex lecture
%   -> Run a second time to get cross-references right
% dvi2ps lecture > lecture.ps
%   -> Merges the figures with the text, can also pipe to lpr
%
\documentstyle[12pt,pocs-header]{article}
\Scribes{Louise Lemaire and David Chaiken}
\Lecturer{Bill Weihl}
\LectureNumber{1}
\LectureDate{September 12, 1990}
\include{macros} % used to include figures in this document
\begin{document}
\MakeScribeTop

\section{Administrative Information}

\begin{table}[h]
\centering
\begin{tabular}{|c|l|} \hline
\multicolumn{1}{|c|}{Handout} &
\multicolumn{1}{c|}{Title} \\ \hline
1 & Course Information \\
2 & Preliminary Course Schedule \\
3 & The Spec Language \\
4 & Example Memory Systems \\ \hline
\end{tabular}
\end{table}
Correction for Handout 4.  On page 2, in {\tt APROC Initialize}:
\begin{tabbing}
space \= replace \= \kill
\> replace \> \verb+do VAR a | c(a)=nil /\ (Set[A].Size{a' | c!a'}) < csize)+\\
\> with \> \verb+do VAR a | c(a)=nil /\ (Set[A].Size{a' | c(a')#nil}) < csize)+\\
\end{tabbing}

For administrative questions about the course, please talk to
Professor Weihl.  Both Professor Weihl and Professor Lampson will be
happy to discuss technical subject matter.  Please read all of the
assigned papers.  It is yet to be determined whether there will be any
exams.

\section{Course Content and Material}

This course is a graduate level introduction to principles of computer
systems.  It will focus on concurrent and distributed systems,
although the first three weeks will develop background issues
in the simpler context of single-site systems.  The theme of the
course will be rigorous specification and reasoning techniques,
applied to the design of systems.  Students will learn how to write
specifications and how to convince themselves (and others) that
distributed and fault-tolerant systems work as they are specified.
{\em Principles of Computer Systems} differs from {\em Computer
Systems (6.853)} in that it does not discuss a series of case studies
to provide design examples.  This course will cover the following topics:
\begin{itemize}
\item {\bf Specifications} are used to abstract the design of a system
from the details of its implementation.  Issues include what is a
specification, what belongs in one, and how are specifications affected by
concurrency and distribution.
\item {\bf Reasoning techniques} are used to prove the correctness of a
system.  We will not discuss techniques at a formal level.
Rather, we will introduce reasoning techniques that are informal and rigorous.
\item {\bf Performance} issues include
design tradeoffs, complexity, and methods for increasing performance.
For example, caching is a prevalent technique for improving
performance.
\item Problems with and methods for achieving various types of {\bf fault-tolerance}.  Emphasis is on building systems that tolerate hardware faults, rather
than on systems that tolerate software and design faults.
\item {\bf Concurrency} is a factor in operating systems and distributed
systems.  After the first three weeks of the course, we will discuss
problems in specifying and reasoning about concurrency.  We will not
cover applications of concurrency for solving individual problems
quickly.
\item {\bf Distributed systems} will also be covered in the latter half of the
course.  We will focus on the characteristics of communication networks in
distributed systems.  Issues include protocols, caching, and replication.
\item {\bf Transactions} are a mechanism for building fault-tolerant, distributed, and concurrent systems.
\item The issues of the {\bf naming} problem will be introduced in the context
of centralized systems, and we will discuss how the problem changes in a 
distributed environment.
\item {\bf Security} is a problem in real-world applications.
\end{itemize}

\section{Principles for Computer System Design}

Various attempts have been made to enumerate a set of basic principles
for computer system design.  For example, see Lampson's paper called
{\em Hints for Computer System Design} in the October, 1983, SIGOPS
{\em Proceedings of the Ninth ACM Symposium on Operating Systems and
Principles}.  Abstraction, tradeoffs, and reasoning techniques are
three important factors in designing systems.

{\em Abstraction} refers to the process of using specifications to
separate the behavior of a system from the details of its implementation.
The art of specification involves deciding which details of system design
are relevant and which are not.  The goal is to provide others with an
understanding of the system, without clouding the explanation with
unimportant details.  {\em Modularity} is a common buzz-word that encapsulates
the benefits of abstraction through good specification.

For example, Figure~\ref{sortfig} shows a graphical specification of a
module that sorts an array of objects.  The specification shows the
input to output transformation performed by the module.  It is a good
specification for two reasons: First, it describes the behavior of the
module, without burdening the reader with the details of its
implementation.  Second, if the implementation does not meet the
system's performance requirements, it can be changed as long as it
still meets the specification.

\begin{figure}
\centerline{\psfig{width=3in,figure=sort.idraw}}
\caption{Specification for a sorting module.}
\label{sortfig}
\end{figure}

The concept of the behavior of a module is well-understood for
sequential systems, but becomes more complicated for concurrent
systems.  The behavior of a single-site system can be defined in terms
of the input to output mapping for each module.  However, a
specification of the behavior of a concurrent or a distributed system
requires the definition of subtle interactions between the modules.
Specifications for modules in concurrent systems are often weaker
than those for modules in sequential systems, due to the effect of
nondeterminism.  Nondeterminism makes it difficult to accurately determine
the detailed behavior of a system without reducing performance.

In concurrent and distributed systems, there are {\em tradeoffs}
between the goals of simple specification and good performance.  The
following example illustrates the tradeoff between performance and
functionality.  Figure~\ref{securefig} shows a number of file servers
and clients that are connected through some sort of network.  {\em
Client B} uses a cache that currently contains a copy of a file
located on {\em Server 2.} Consider a situation in which {\em Server
2} wishes to change the permission settings for the file such that
{\em Client B} will no longer be permitted to access it.  Two possibilities
for specifying the behavior of the permission change are
\begin{enumerate}
\item By the time that the permission change routine returns, {\em Client B}
will be denied access to the file.
\item Within some delta of time (which may or may not be specified), {\em Client B} will be denied access.
\end{enumerate}
Although the first option is easier to specify and easier to reason
about, the second can provide significantly higher performance.  This
performance/functionality tradeoff is resolved by the requirements of
the system.  In concurrent and distributed environments, the tradeoff is
complicated by factors such as the cost of communication between
system components.

\begin{figure}
\centerline{\psfig{width=3in,figure=security.idraw}}
\caption{Example of the performance/functionality tradeoff.}
\label{securefig}
\end{figure}

{\em Reasoning techniques} are used to verify the correctness of a
system, once it has been specified.  Abstraction functions and
representation invariants are examples of familiar techniques that are
used in the sequential world.

\section{The Spec Language}

The {\em Spec} language will be used in this course to write both
specifications and implementations.  The language is based on Edsger
Dijkstra's ``guarded commands,''\footnote{See Dijkstra's paper called
{\em Guarded Commands, Nondeterminacy and Formal Derivation of
Programs} in the August, 1975 issue of {\em Communications of the
ACM.}} extended by Greg Nelson, and augmented with constructs for
concurrency and atomicity by Butler Lampson.  Although some
researchers (such as John Guttag) advocate separate languages for
specification and implementation, we will use a single language for
the purposes of simplicity.  {\em Spec} is used to write
specifications and implementations in terms of the operational
semantics of a system.

Given that we will use only one language for both purposes, how is it
possible to tell the difference between a specification and an
implementation?  The answer depends on the level of abstraction: ``One
person's implementation is another person's specification.''  However,
some heuristic rules can be applied.  For example, it is not usually
appropriate to use universal or existential quantifiers in an
implementation.  When written in {\em Spec}, specifications and
implementations are composed of modules.  Each module contains type
definitions, variable declarations, routine declarations, and a body.

The syntax and semantics of {\em Spec} are specified in Handout 3, and
Handout 4 contains three examples of the use of the language.  The
examples illustrate a number of features.
\begin{itemize}
\item {\tt *} is used to represent every element of a set.
\item Case is significant in the language.  Type and procedure identifiers
begin with a capital letter.  Variables in lower case are assumed to
be instances of types specified in upper case.  For example, {\tt m} is
of the type {\tt M}.
\item Atomicity brackets are used to specify that sequences of statements
must appear to occur atomically, although they may not actually be implemented
that way.
\item The {\tt HAVOC} statement is used to indicate the dire consequence
of an unfulfilled precondition.  It replaces the ``requires'' clause used
in some specification languages.
\item Nondeterministic choice is indicated by the {\tt []} symbol.
\end{itemize}

{\em Spec} allows the definition of an abstraction function, which
maps the states of an implementation to the states of its
specification.  In general, a proof that an implementation meets its
specification is done by showing a homomorphism between the state
transitions in the implementation space and in the specification
space.  See Figure~\ref{prooffig} for an illustration of this process.

\begin{figure}
\centerline{\psfig{width=4in,figure=proof.idraw}}
\caption{The technique for proving that an implementation
meets its specification.}
\label{prooffig}
\end{figure}

\end{document}