\mainsection{Programmatic Restarting}
\label{sec:restart}
Because, unlike in SPDZ, the offline and online phases are totally
integrated, it can takes a long time for the queues of pre-processed
triples to be full. This means that quickly starting an instance to
run a short program can be very time-consuming. For reactive systems
in which the precise program which is going to be run is not known
until just before execution this can be a problem.
We therefore provide a mechanism, which we call \verb+RESTART+, to
enable a program to {\em programatically} restart the online runtime, whilst 
still maintaining the current offline data.
In the byte-code this is accessed by the op-code \verb+RESTART+
and in MAMBA it is accessed by the function \verb+restart(Schedule &schedule)+.
Both must be called in online thread zero.

The basic model is as follows.
You start an instance of the SCALE engine with some (possibly
dummy) program. This program instance will define the total number
of online threads you will ever need; this is because we do not
want a restart operation to have to spawn new offline threads.
You then ensure that the last operation performed by this
program is a \verb+RESTART+/\verb+restart(Schedule &schedule)+.
This {\em must} be executed in thread zero, and to avoid undefined
behaviour {\em should} only happen when all other thread programs
are in a wait state.

After calling \verb+RESTART+/\verb+restart(Schedule &schedule)+
the runtime waits for a trigger to be obtained
from {\em each} player on the IO functionality (see
Section \ref{sec:IO}).
This trigger can be anything, but in our default IO class it
is simply each player needing to enter a value on the standard
input.
The reason for this triggering is that the system which is
calling SCALE {\em may} want to replace the underlying
schedule file and tapes; thus enabling the execution of
a new program entirely.

The specific \verb+restart(Schedule &schedule)+ function in the  
IO functionality will now be executed.
In the provided variant of IO functionality, given in
\verb+Input_Output_Simple+, the schedule file is reloaded 
from the {\em same directory} as the original program instance.
This also reloads the tapes etc.

You could implement your own \verb+restart(Schedule &schedule)+ function in your
own IO functionality which programmatically alters
the underlying schedule to be executed, via the argument to \verb+restart+. 
This enables a more programmatic control of the SCALE engine.

To see this in operation we provide the following simple
examples, in \verb+Programs/restart_1/restart.mpc+
and \verb+Programs/restart_2/restart.mpc+.
To see these in operation execute the following commands
from the main directory (assuming you are using the
default IO functionality,
\begin{verbatim}
            \cp Programs/restart_1/restart.mpc Programs/restart/
            ./compile.py Programs/restart
\end{verbatim}
Now run the resulting program as normal, i.e. using \verb+Programs/restart+
as the program.
When this program has finished it asks (assuming you are
using the default IO class) for all players to enter
a number. {\em Do not do this yet!}
First get the next program ready to run by executing
\begin{verbatim}
        \cp Programs/restart_2/restart.mpc Programs/restart/
        ./compile.py Programs/restart
\end{verbatim}
Now enter a number on each players console, and 
the second program should now run.
Since it also ends with a \verb+RESTART+ byte-code, you can
continue in this way forever.

\subsection{Memory Management While Restarting}
As part of the restart functionality we also add some extra commands to aid
safety of the overall system.

The first of these is \verb+clear_memory()+, which corresponds to the byte-code
\verb+CLEAR_MEMORY+.
What this does is initialize all system memory to zero. Thus before calling a 
\verb+restart()+ one can zero out all the memory, meaning the memory cannot be
used by the next program to be executed. This might be useful when you want to
avoid the next program to be run accessing memory from the current state. This
could be a concern if you are unsure if the byte-code to be executed does not
contain invalid memory accesses by mistake. Thus \verb+CLEAR_MEMORY+ can be
considered as an instruction which avoids security errors due to programmer
mistakes.

Note that if \verb+clear_memory()+ MAMBA instruction is executed in one thread, 
then this means the memory in any other thread will now be not what is expected. 
So the instruction should only really be executed in thread zero, once all other threads have
finished.
A demonstration of the \verb+clear_memory()+ command called from MAMBA is
available in the program directory \verb+/Programs/mem_clear_demo+.

The second command is \verb+clear_registers()+, which corresponds to the
byte-code \verb+CLEAR_REGISTERS+.
This resets the registers in the calling processor to zero; it does nothing
to the register files in the other threads.
The purpose is again to avoid mistakes from programmers. One should consider
emitting this instruction at the end of the code of every thread.
However, the instruction ordering when compiled from MAMBA {\em may} be
erratic (we have not fully tested it); thus its usage should be considered
experimental.
The exact order of it being emitted can be checked by running the player
with a negative verbose number (which outputs the instructions being executed
in the order they are found).
Again the usage is demonstrated in the program  directory \verb+/Programs/mem_clear_demo+.

