%\section{The Abstract Model}
\label{abstract-model}

\begin{figure}
  \centerline{\psfig{figure=exec-model.id,height=4cm}}
  \caption{\LBM\ Run Time Model}
  \label{exec-model}
\end{figure}

This section presents an abstract model for
the run-time components of a system derived
from a LOTOS specification.
There are three basic building blocks
(see figure~\ref{exec-model}):
a collection of BUTs,
a data machine,
and a run-time support.
Their functionality and interrelationship is described below.

The BUTs
(for Behaviour UniTs),
are derived from LOTOS behaviour specification.
There is initially a single BUT that behaves as the main behaviour in
the specification.
As concurrent control threads are spawn,
further BUTs appear.

The data machine provides an implementation of the data specification.

The run-time support
(sometimes called Kernel)
provides centralized control on active BUTs,
keeps information about BUTs relation patterns,
selects partners for a rendezvous \cite{topo:rendezvous},
and schedules the allocation of time slots for BUTs activities.

BUTs call the data machine for data evaluation,
and guards resolution.

The run-time support calls the data machine
for predicate resolution,
and for deciding equality of terms according to initial semantics.

BUTs are activated under control of the kernel.
It holds a table of active BUTs
that encompasses both the code to execute and their private data.
It exactly reflects the role of an O.S. kernel that keeps a table of
active processes: code and data segments.

BUTs have independent activity except for informing the kernel of
relevant events that require coordination with other BUTs.
The kernel provides system calls to inform of synchronization patterns
and spawning of new BUTs.
Furthermore,
the kernel recovers control when the BUT makes an offer to participate
in an event.

The behaviour of BUT closely resembles that of processes in
conventional O.S.
User processes get time slots from the kernel.
The processes rely on the kernel to coordinate with other processes,
and use system calls to access kernel data structures.

The rest of the paper is devoted to describe BUTs in terms of a
virtual behaviour machine.

\subsection{Related Work}
Although the authors are not aware of any other virtual machine for
LOTOS,
several papers have been published that propose their own run-time
organization.
For may of them,
blocks with a similar functionality to our BUTs may be identified.
Then,
the virtual machine described below
may be used in several other environments.

It seems that many of the proposed implementation models for LOTOS
\cite{dubuis:algorithm,gao,nomura,sjodin,bochmann:distributed-lotos}
rely on some activity units modeling the behaviour of independent
parts of the specification,
and that these units rely on external communication to resolve
rendezvous.
The kernel may be centralized as in \cite{nomura},
or more or less distributed as in
\cite{dubuis:algorithm,gao,sjodin,bochmann:distributed-lotos}.
As far as this minimal model is followed,
\LB\ may be used as an intermediate stage for code generation;
isolating front-end analysis,
and back-end code generation.

