From: Mart Lubbers Date: Sat, 8 Jul 2017 10:35:29 +0000 (+0200) Subject: rename semantics X-Git-Tag: final~20 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=ce72d1f8bb05ef88c3b8dcf2a3a4dd81c5c01557;p=msc-thesis1617.git rename semantics --- diff --git a/conclusion.discussion.tex b/conclusion.discussion.tex index 2bd77d3..e5b10af 100644 --- a/conclusion.discussion.tex +++ b/conclusion.discussion.tex @@ -10,8 +10,8 @@ the existing \gls{SDS}-based systems. At the moment the \emph{POSIX}-client is 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:} @@ -75,8 +75,8 @@ using simple syntactic transformations. 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. diff --git a/mtaskext.bytecode.tex b/mtaskext.bytecode.tex index e880353..1a365be 100644 --- a/mtaskext.bytecode.tex +++ b/mtaskext.bytecode.tex @@ -140,7 +140,7 @@ instance userLed ByteCode where 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 @@ -168,8 +168,8 @@ instance noOp ByteCode where 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 diff --git a/mtaskext.taskstrat.tex b/mtaskext.taskstrat.tex index 040e461..07723f1 100644 --- a/mtaskext.taskstrat.tex +++ b/mtaskext.taskstrat.tex @@ -2,26 +2,39 @@ The current \gls{mTask} engine for devices does not support \glspl{Task} in the 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} diff --git a/todo.txt b/todo.txt index efdb1c9..2a5889a 100644 --- a/todo.txt +++ b/todo.txt @@ -1,5 +1,4 @@ intro: Problem statement en introductie uitwijden -mtask: semantics anders noemen emtsk: semantics, anders noemen en voorbeelden geven in strategies emtsk: Voorbeeldje voor namedsds emtsk: examples, factorial vervangen