\subsubsection{\iTasks{} task}
\mTask{}s are not regular tasks, they can not be combined with task
combinators. Moreover \mTask{}s can not communicate directly with each other or
with the server. Indirect communication is possible through a special type of
SDSs that lives solely within the mother task and the microcontroller.

An \mTask{} controller is just another \iTasks{} task and can be instantiated.
The controller task will manage the devices and keep track of the data
structures.

Devices can be added to the controller by giving a specification of the
communication and some properties of the device. Not all devices are the same
so a data structure containing properties will have to be devised.

An \mTask{} can be added through the \CI{runmTask} function that from a given
\mTask{} returns a \CI{Task Int}. The \CI{Int} denotes the unique identifier of
the task that can later on be used to kill a task even when it is not finished.
During initialization the task value is \CI{NoValue}. When the initialization
is done and the task is loaded the value becomes an unstable \CI{Int} value
that denotes the task identification. When the task is finished the value
becomes stable and no interaction can be done with the type from then on. Tasks
can be deleted at runtime by using the \CI{delmTask} function that will return
a task of type \CI{Bool} to indicate success. All type signatures are available
in Listing~\ref{lst:mothertask}.

\begin{lstlisting}[language=Clean,label={lst:mothertask}]
mTask :: DeviceSpec -> Task ()
addmTask :: (ByteCode a p) -> Task Int
delmTask :: Int -> Task Bool
\end{lstlisting}

\subsubsection{Shared Data Sources}
\todo{redo this for push updates from server}
\todo{say something about type constraints of SDSs}
\todo{explain why there is no update function(closure, bytecode}
\mTask{}s can use SDSs for means of storing information and for communicating
back to the server. Communication can be slow and therefore SDSs are only
updated when a task specifically asks for it through the bytecode instructions
for publishing and getting SDS values. This means that the SDS functions a
little different from SDSs used in general \iTasks{} in the sense that they can
run out of sync. For now we solve this by giving the \mTask{} system priority
and adhering to his store. In practise this means that it is not mandatory to
first fetch the latest SDS value before updateing and possibly publishing it.
The responsibility lies with the programmer when such behaviour is necessary.

The mothertask manages the SDSs per device. This means that it is not possible
in principle to have one SDS shared over multiple devices. This does not mean
that it is not possible at all. With a suitable task doing the synchronization
one can realize this functionality. SDSs also never leave the domain of the
mothertask. It is not possible to use an existing SDS for the purpose of an
\mTask{}, SDSs used in \mTask{} are always instantiated on the fly to prevent
confusion and race conditions on the data. This results in the following
situation.
