architecture/itasks.tex

   1 \subsubsection{\iTasks{} task}
   2 \mTask{}s are not regular tasks, they can not be combined with task
   3 combinators. Moreover \mTask{}s can not communicate directly with each other or
   4 with the server. Indirect communication is possible through a special type of
   5 SDSs that lives solely within the mother task and the microcontroller.
   6
   7 An \mTask{} controller is just another \iTasks{} task and can be instantiated.
   8 The controller task will manage the devices and keep track of the data
   9 structures.
  10
  11 Devices can be added to the controller by giving a specification of the
  12 communication and some properties of the device. Not all devices are the same
  13 so a data structure containing properties will have to be devised.
  14
  15 An \mTask{} can be added through the \CI{runmTask} function that from a given
  16 \mTask{} returns a \CI{Task Int}. The \CI{Int} denotes the unique identifier of
  17 the task that can later on be used to kill a task even when it is not finished.
  18 During initialization the task value is \CI{NoValue}. When the initialization
  19 is done and the task is loaded the value becomes an unstable \CI{Int} value
  20 that denotes the task identification. When the task is finished the value
  21 becomes stable and no interaction can be done with the type from then on. Tasks
  22 can be deleted at runtime by using the \CI{delmTask} function that will return
  23 a task of type \CI{Bool} to indicate success. All type signatures are available
  24 in Listing~\ref{lst:mothertask}.
  25
  26 \begin{lstlisting}[language=Clean,label={lst:mothertask}]
  27 mTask :: DeviceSpec -> Task ()
  28 addmTask :: (ByteCode a p) -> Task Int
  29 delmTask :: Int -> Task Bool
  30 \end{lstlisting}
  31
  32 \subsubsection{Shared Data Sources}
  33 \todo{redo this for push updates from server}
  34 \todo{say something about type constraints of SDSs}
  35 \todo{explain why there is no update function(closure, bytecode}
  36 \mTask{}s can use SDSs for means of storing information and for communicating
  37 back to the server. Communication can be slow and therefore SDSs are only
  38 updated when a task specifically asks for it through the bytecode instructions
  39 for publishing and getting SDS values. This means that the SDS functions a
  40 little different from SDSs used in general \iTasks{} in the sense that they can
  41 run out of sync. For now we solve this by giving the \mTask{} system priority
  42 and adhering to his store. In practise this means that it is not mandatory to
  43 first fetch the latest SDS value before updateing and possibly publishing it.
  44 The responsibility lies with the programmer when such behaviour is necessary.
  45
  46 The mothertask manages the SDSs per device. This means that it is not possible
  47 in principle to have one SDS shared over multiple devices. This does not mean
  48 that it is not possible at all. With a suitable task doing the synchronization
  49 one can realize this functionality. SDSs also never leave the domain of the
  50 mothertask. It is not possible to use an existing SDS for the purpose of an
  51 \mTask{}, SDSs used in \mTask{} are always instantiated on the fly to prevent
  52 confusion and race conditions on the data. This results in the following
  53 situation.