mtask.scheduling.tex

   1 The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
   2 alongside the code for the \glspl{Task}. This engine will execute the
   3 \gls{mTask}-\glspl{Task} according to certain rules and execution strategies.
   4 \gls{mTask}-\glspl{Task} do not behave like functions but more like
   5 \gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
   6 out or when it is launched by another \gls{mTask}. When an \gls{mTask} is
   7 queued it does not block the execution and it will return immediately while the
   8 actual \gls{Task} will be executed anytime in the future.
   9
  10 The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
  11 scheduling strategy. This engine expressed in pseudocode is listed as
  12 Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
  13 time. When the waiting time has not passed; the delta is subtracted and the
  14 \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed
  15 they are executed. When an \gls{mTask} opts to queue another \gls{mTask} it
  16 can just append it to the queue.
  17
  18 \vspace{1em}
  19 \begin{algorithm}[H]
  20         \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
  21
  22         $t\leftarrow\text{now}()$\;
  23         \Begin{
  24                 \While{true}{
  25                         $t_p\leftarrow t$\;
  26                         $t\leftarrow\text{now}()$\;
  27                         \If{notEmpty$($queue$)$}{
  28                                 $task\leftarrow \text{queue.pop}()$\;
  29                                 $task$.wait $\leftarrow task$.wait $-(t-t_p)$\;
  30                                 \eIf{$task.wait>t_0$}{
  31                                         queue.append$(task)$\;
  32                                 }{
  33                                         run\_task$(task)$\;
  34                                 }
  35                         }
  36                 }
  37         }
  38         \caption{Engine pseudocode for the \gls{C}- and
  39                 \gls{iTasks}-view}\label{lst:engine}
  40 \end{algorithm}
  41 \vspace{1em}
  42
  43 To achieve this in the \gls{EDSL} a \gls{Task} class is added that work in a
  44 similar fashion as the \texttt{sds} class. This class is listed in
  45 Listing~\ref{lst:taskclass}. \glspl{Task} can have an argument and always have
  46 to specify a delay or waiting time. The type signature of the \CI{mtask} is
  47 complex and therefore an example is given. The aforementioned Listing
  48 shows a simple specification containing one \gls{Task} that increments a value
  49 indefinitely every one seconds.
  50
  51 \begin{lstlisting}[language=Clean,label={lst:taskclass},%
  52         caption={The classes for defining \glspl{Task}}]
  53 class mtask v a where
  54   task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ...
  55
  56 count = task \count = (\n.count (lit 1000) (n +. lit 1)) In
  57         {main = count (lit 1000) (lit 0)}
  58 \end{lstlisting}