% 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
%     threads.ps:      first figure, created with idraw
%     commute.ps:      second figure, created with idraw
%     timestamps.ps:   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}
\Scribe{David E. Langworthy}
\Lecturer{William Weihl}
\LectureNumber{13}
\LectureDate{October 28, 1991}
\include{macros} % used to include figures in this document
\begin{document}
\MakeScribeTop

\section{Administrata}

\begin{tabular}{|c|l|} \hline
Handout & \multicolumn{1}{c|}{Title} \\\hline
29\rule[-.75cm]{0cm}{1.5cm}      & \parbox{5in}{David Lomet, {\em Recovery for Shared Disk Systems Using
Multiple Redo Logs}, Digital Equipment Corporation, CRL 90/4, October,
1990. }\\\hline
30\rule[-.5cm]{0cm}{1cm}      & Solutions to Problem Set 2. \\\hline
21\rule[-.5cm]{0cm}{1cm}      & Concurrent Transactions, Butler Lampson. \\\hline
\end{tabular}

\section{Corrections}

There are 2 mistakes on handout 27.  The first was noted by Umesh
Maheshwari and the second by Butler.

\begin{enumerate}

\item Invariant 1 reads $ sb +l1 = sb + sl - sul$ should read
$S.s0().toB + pl + l1 = S.s0().toB + pl + sl - sul$ because
``$ sb$ can contain uncommitted stuff''.

\item Invariant 4 states $ S.s0().toB + pl = sb$ when in fact the
implementation guarantees only the weaker invariant that $ S.s0().toB
+ pl + sl = sb + sl$.

\end{enumerate}

\section{Shadowing}

The lecture began with a short section describing shadowing, an
alternative to logging described in the last lecture. When using
shadowing instead of overwriting a page the new version of the page is
written to free space on the disk.  The in-memory representation is
then changed to reference the new page.  If there is a crash the in
memory representation will be lost and the old version on disk will be
used.  Clearly this cannot go on forever.  There must be some sort of
checkpoint mechanism to change old\_sb to new\_sb.  

The advantage to this scheme is that there is no undo complexity.
A transaction can update pages on disk and if it aborts or there is a
crash all that needs to be changed is the in-memory representation.

\section{Concurrent Transactions}

The last lecture covered recovery for a serial system where the only
sort of concurrency allowed is a crash.  Removes this restriction and
allows concurrent actions.  Concurrency control and recovery are
90\% decoupled in the real world.  For the purposes of this class they
will be considered 100\% decoupled.

Instead of one client there will be multiple clients

\begin{figure}
\centerline{\psfig{figure=threads.ps}}
\caption{The actions of two concurrent threads.}
\label{threads}
\end{figure}

Errors in a concurrent system can be very tricky to debug.  Chances
are that the bug cannot be found by looking at one code file.  The
interaction between many source documents must be considered.  More
importantly the bugs will be intermittent and near impossible to
replicate.  Often debugging code will slow the clients down and add in
synchronization that prevents the bug from manifesting itself.

The motivation for concurrent transactions is the same as last week.
We want to use sequential reasoning so we cannot allow interleaved
updates.  A transaction plays the same roll as a lock, but over
multiple data items.  It allows the programmer to choose an invariant,
assume the invariant is true at the beginning of the transaction and
make the invariant true at the end.  

In order to get atomicity with generality there are 2 requirements:
\begin{itemize}

\item The transactions must be serialized.  That is each transaction
must appear to run entirely before or after each other transaction.

\item The transactions must be externally consistent.  Within
a single thread of control, if one transaction ends before another
begins the first transaction must be serialized before the second.

\end{itemize}

The remainder of the lecture covered the specification of concurrent
transactions and two very different means of implementing the
specification.


\section{Specification}

The requirements mentioned above restrict the behavior of all
transactions that actually commit.  It does not restrict the behavior
of uncommitted transactions.  In theory uncommitted transactions can
behave arbitrarily.  In reality this is not such a good thing.
Suppose an automated trading program noticed it had a cash balance of
\$73,394,892 and put in an order for the Empire State building.  This
problem results from a transaction that cannot commit interacting with
the outside world.  There are many forms of interaction which can take
place.  Some are very subtle, non-termination or modification of
shared memory for example.  Others are harder to compensate for, the
launching of a missile or causing the system to crash.  The
specification given in handout 31 says something about the behavior of
uncommitted transactions as well as committed transactions.

\section{Two Phase Locking}

This scheme is by far the most popular concurrency control
implementation.  Locking forbids operations which do
not commute from completing.  The commutative property allows
operations from different transactions to be reordered into a so that
it will appear that the transactions ran serially as desired.  In the
example, operation {\sf A12} must commute back over {\sf A21} and {\sf
A22}.  Alternatively, {\sf A12} could commute forward over {\sf A23}
and {\sf A24} if {\sf A11} commutes forward over {\sf A21}, {\sf A22},
{\sf A23}, and {\sf A24}.

\begin{figure}
\centerline{\psfig{figure=commute.ps}}
\caption{Two ways interleaved actions could commute to yield a serializable execution.}
\label{commute}
\end{figure}

\section{Multi-Version Timestamps}

In this implementation each transaction is given a {\em timestamp}.
The timestamps determine the serialization order of the transactions.
As expected a transaction with a later timestamp is later in the
serialization order.  The way scheme works is very simple.  All
operations of a transaction are made to appear as if they took place at
the instant specified by the transaction's timestamp.


\begin{figure}
\centerline{\psfig{width=6in,figure=timestamps.ps}}
\caption{Legal actions under Multi-Version Timestamping.}
\label{timestamps}
\end{figure}


This illustration shows the history for one data item and several
transactions.  Transactions with timestamps 12 and 37 have already
operated on the object.  Transaction 12 wrote a new value into the
object and transaction 37 read that value.  The implementation does
not forbid a transaction with an earlier timestamp, say 6, from
writing another value, because this will not effect the value read at
time 37.  Further, it does not restrict a transaction with a later
timestamp, say 66, from modifying the value even though the transaction
with a timestamp of 37 may still be running when the update occurs.
The implementation does forbid a transaction with a timestamp
in between the two from updating the data.  This modification would
effectively change the value that was read at time 37, so it is
disallowed.  The conflict may be resolved by aborting either the
transaction that is attempting to write the data or the transaction
that read the data.  In this scheme reads are never blocked.  They
simply block further writes.  

Note that this scheme is fundamentally different than locking.  When a
transaction blocks it cannot simply wait until some time in the future
when the operation can complete as in locking.  As soon as a
transaction blocks it cannot continue work.  Either it or another
transaction must be aborted.

\end{document}