rename semantics

[msc-thesis1617.git] / mtaskext.tasksem.tex

diff --git a/mtaskext.tasksem.tex b/mtaskext.tasksem.tex
deleted file mode 100644 (file)
index 040e461..0000000
--- a/mtaskext.tasksem.tex
+++ /dev/null
@@ -1,27 +0,0 @@
-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:
-
-\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}
-
-               \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}
-
-               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.
-\end{itemize}