update

[ri1617.git] / architecture / itasks.tex

diff --git a/architecture/itasks.tex b/architecture/itasks.tex
index 98683e7..acc5da1 100644 (file)
--- a/architecture/itasks.tex
+++ b/architecture/itasks.tex
@@ -1,4 +1,27 @@
 \subsubsection{\iTasks{} task}
+\mTask{}s are no regular tasks in the sense that they can 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.
+
+\todo{Dit wat hieronder staat omschrijven}
+
 To make the integration of \mTask{}s in \iTasks{} more orthogonal we need a
 special kind of task that serves as a mothertask that has the type visible in
 Listing~\ref{lst:mothertask}. At first the system must be initialized with the
@@ -19,8 +42,20 @@ delmTask :: Int -> Task Bool
 
 \subsubsection{Shared Data Sources}
 \mTask{}s can use SDSs for means of storing information and for communicating
-with 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.
+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.
 
-\todo{Uitleg over synchronisatie als de sds op de server veranderd}
+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.