architecture/itasks.tex

   1 \subsubsection{\iTasks{} task}
   2 \mTask{}s are no regular tasks in the sense that they can 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.
  22
  23 \todo{Dit wat hieronder staat omschrijven}
  24
  25 To make the integration of \mTask{}s in \iTasks{} more orthogonal we need a
  26 special kind of task that serves as a mothertask that has the type visible in
  27 Listing~\ref{lst:mothertask}. At first the system must be initialized with the
  28 first given function. This will setup the necessary communication tasks and
  29 SDSs used for interal storage and communication. This task is automatically
  30 started when the system boots up. To add a task one has to call \CI{addmTask}
  31 which will send the task to the system and evaluate it. Currently the only way
  32 of getting info back is through SDSs that are used in the \mTask. Some tasks
  33 are designed to run indefinite, for example temperature monitoring, and to
  34 remove them the \CI{delmTask} function is introduced that will remove the task
  35 and return a success value.
  36
  37 \begin{lstlisting}[language=Clean,label={lst:mothertask}]
  38 mTask :: DeviceSpec -> Task ()
  39 addmTask :: (ByteCode a p) -> Task Int
  40 delmTask :: Int -> Task Bool
  41 \end{lstlisting}
  42
  43 \subsubsection{Shared Data Sources}
  44 \mTask{}s can use SDSs for means of storing information and for communicating
  45 back to the server. Communication can be slow and therefore SDSs are only
  46 updated when a task specifically asks for it through the bytecode instructions
  47 for publishing and getting SDS values. This means that the SDS functions a
  48 little different from SDSs used in general \iTasks{} in the sense that they can
  49 run out of sync. For now we solve this by giving the \mTask{} system priority
  50 and adhering to his store. In practise this means that it is not mandatory to
  51 first fetch the latest SDS value before updateing and possibly publishing it.
  52 The responsibility lies with the programmer when such behaviour is necessary.
  53
  54 The mothertask manages the SDSs per device. This means that it is not possible
  55 in principle to have one SDS shared over multiple devices. This does not mean
  56 that it is not possible at all. With a suitable task doing the synchronization
  57 one can realize this functionality. SDSs also never leave the domain of the
  58 mothertask. It is not possible to use an existing SDS for the purpose of an
  59 \mTask{}, SDSs used in \mTask{} are always instantiated on the fly to prevent
  60 confusion and race conditions on the data. This results in the following
  61 situation.