the reference client and contains debugging code. Adding a simulation view to
the system allows for easy interactive debugging. However, it might not be
easy to devise a simulation tool that accurately simulates the \gls{mTask}
-system on some levels. The semantics can be simulated but timing and peripheral
-input/output are more difficult to simulate properly.
+system on some levels. The execution strategy can be simulated but timing and
+peripheral input/output are more difficult to simulate properly.
\subsection{Optimization}
\paragraph{Multitasking on the client:}
Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
the current system this type of logic has to take place on the server side.
Adding this functionality to the bytecode-view allows greater flexibility,
-easier programming and less communication resources. Adding these semantics
-requires modifications to the client software and extensions to the
+easier programming and less communication resources. Adding this type of
+scheduling requires modifications to the client software and extensions to the
communication protocol since relations between \glspl{Task} also need to be
encoded and communicated.
ledOff l = op l BCLedOff
\end{lstlisting}
-\subsection{Control Flow}
+\subsection{Control Flow}\label{ssec:control}
Implementing the sequence operator is very straightforward in the bytecode
view. The function just sequences the two \glspl{RWST}. The
implementation for the \emph{If} statement speaks for itself in
noOp = BC (pure ())
\end{lstlisting}
-The semantics for the \gls{mTask}-\glspl{Task} bytecode view are different from
-the semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start
+The scheduling in the \gls{mTask}-\glspl{Task} bytecode view is different from
+the scheduling in the \gls{C} view. \glspl{Task} in the \gls{C} view can start
new \glspl{Task} or even start themselves to continue, while in the bytecode
view, \glspl{Task} run indefinitely, one-shot or on interrupt. To allow
interval and interrupt \glspl{Task} to terminate, a return instruction is
sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
main program that executes code and launches \glspl{Task}. It was also possible
to just have a main program. The current \gls{mTask}-system only supports main
-programs. Sending a \gls{Task} always goes together with choosing a scheduling
-strategy. This strategy can be one of the following three strategies:
+programs which are the \glspl{Task} in their entirety. However, this results in
+a problem. \glspl{Task} can not call other \glspl{Task} nor themselves.
+Therefore, execution strategies have been added. Sending a \gls{Task} always
+goes together with choosing a scheduling strategy. This strategy can be one of
+the following three strategies:
\begin{itemize}
\item\CI{OneShot}
- \CI{OneShot} takes no parameters and means that the \gls{Task} will run
- once and will then be removed automatically. This type of scheduling
- is useful, for example, in retrieving sensor information on request of
- the user.
- \item\CI{OnInterval}
+ The \CI{OneShot} strategy consists of executing the \gls{Task} only
+ once. In \gls{IoT} applications, often the status of a peripheral or
+ system has to be queried only once on the request of the user. For
+ example in a thermostat, the temperature is logged every 30 minutes.
+ However, the user might want to know the temperature at that exact
+ moment, and then they can just send a \CI{OneShot} \gls{Task} probing
+ the temperature. After execution, the \gls{Task} will be removed from
+ the memory of the client.
+ \item\CI{OnInterval Int}
- \CI{OnInterval} has the number of milliseconds to wait in between
- executions as a parameter. \Glspl{Task} running with this scheduling
- method are executed at predetermined intervals.
- \item\CI{OnInterrupt}
+ \CI{OnInterval} is a execution strategy that executes the \gls{Task}
+ in the given number of milliseconds. This strategy is very useful for
+ logging measurements on an interval. Moreover, the strategy can be
+ (ab)used to simulate recursion. \glspl{SDS} store global % chktex 36
+ information and is persistent. The \CI{retrn} instruction --- as will
+ be shown in Section~\ref{ssec:control} --- can then be used to
+ terminate. Therefore, \glspl{Task} can be crafted that recursively call
+ themselves using a \gls{SDS} to simulate arguments.
+ \item\CI{OnInterrupt Int}
- The last scheduling method is running \glspl{Task} on a specific
- interrupt. Unfortunatly, due to time constraints and focus, none of the
- current client implementations support this. Interrupt scheduling is
- useful for \glspl{Task} that have to react on a certain type of
- hardware event such as the press of a button.
+ Finally, a scheduling method is available that executes a \gls{Task}
+ when a given interrupt is received. This method can be useful to launch
+ a \gls{Task} on the press on hardware events such as the press of a
+ button. Unfortunately, due to time constraints and focus, this
+ functionality is only built in the protocol, none of the current client
+ implementations support this.
\end{itemize}
repositories / msc-thesis1617.git / commitdiff