\section{The Synchronization Fault Avoidance System}

The previous three sections have summarized our past and proposed work
in three areas: concurrent computation modeling, predicate detection
and predicate control. We apply our new results in these areas to the
design of a synchronization fault avoidance system. In this section, we
describe the envisioned operation of the system and the preliminary
high-level design of the prototype. 

\subsection{Operation of the System}
The types of synchronization faults would be specified by the user.
For example, the user may specify that race conditions must be avoided
for certain critical shared data objects.

The user would then run the system under the supervision of the fault
avoidance system. Under fault-free operation, the fault avoidance
system would act as a tracing and monitoring system.  It would trace
the potential causality between events and would monitor the execution
to detect synchronization faults. The tracing action would involve
overhead that must be minimized.  This is an important issue for the
study of the practical utility of the potential causality model. The
monitoring action may be done off-line (optimistic) and would,
therefore, not introduce any additional interference. (However, in the
case of output commit, the monitoring may have to be on-line or pessimistic.)

In case a fault is detected, the system must decide which point to 
roll back to. At the minimum it must roll back to a state before the
earliest detected fault. 

Next, with the trace of the computation, it would apply an off-line
predicate control strategy to attempt to avoid the fault. If this is
possible then we have a guaranteed computation that would avoid the
fault. The system would be replayed with the added synchronizations to
ensure that the fault is avoided.

On the other hand, if the off-line predicate control is impossible
(which can be decided efficiently off-line), then the system must be
run to deliberately avoid the same computation and produce a new
computation in the hope that the fault does not recur. In case the same
fault recurs, a decision may be made to roll-back even further to see
if that improves the chances of avoiding the fault. An extreme case of
this mechanism would be rolling back to the beginning (which is the
only option in the absence of a fault avoidance system).

For examples of the intended synchronization faults to be detected
and how they are to be avoided, refer to the application subsections
of sections 2, 3, and 4.

\subsection{Design of the System}

\begin{figure}
\centerline{\epsfbox{Figures/design.eps}}
\caption{Design of the Synchronization Fault Avoidance System \label{design-fig}}
\end{figure}

The high-level design of the system showing its break-up into
components is shown in figure~\ref{design-fig}.  The {\em system under
supervision\/} is under the observation/control of three mechanisms: \\
\indent{\bf Tracing:} This traces the causal order between events.\\
\indent{\bf Rollback:} This rolls back the system to a point in the trace.\\
\indent{\bf Replay:} This replays a given trace.\\
The implementation of these mechanisms is heavily dependent on the
choice of programming language, programming environment, operating system, etc.
These mechanisms are used by the two main components of the fault
avoidance system which are independent of the programming
language, operating system, etc.:\\
\indent {\bf Fault Detection:} This implements the relevant predicate detection algorithm.\\
\indent {\bf Fault Avoidance:} This implements the relevant predicate control algorithm.\\
Note that this design is preliminary and we have left a number of design
choices open-ended.
