more comments

[msc-thesis1617.git] / mtask.scheduling.tex

diff --git a/mtask.semantics.tex b/mtask.scheduling.tex
similarity index 89%
rename from mtask.semantics.tex
rename to mtask.scheduling.tex
index bf8b910..168b6c6 100644 (file)
--- a/mtask.semantics.tex
+++ b/mtask.scheduling.tex
@@ -1,6 +1,6 @@
 The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
 alongside the code for the \glspl{Task}. This engine will execute the
-\gls{mTask}-\glspl{Task} according to certain rules and semantics.
+\gls{mTask}-\glspl{Task} according to certain rules and execution strategies.
 \gls{mTask}-\glspl{Task} do not behave like functions but more like
 \gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
 out or when it is launched by another \gls{mTask}. When an \gls{mTask} is
@@ -8,7 +8,7 @@ queued it does not block the execution and it will return immediately while the
 actual \gls{Task} will be executed anytime in the future.
 
 The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
-semantics. This engine expressed in pseudocode is listed as
+scheduling strategy. This engine expressed in pseudocode is listed as
 Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
 time. When the waiting time has not passed; the delta is subtracted and the
 \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed
@@ -53,5 +53,6 @@ indefinitely every one seconds.
 class mtask v a where
   task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ...
 
-count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 1000) Zero}
+count = task \count = (\n.count (lit 1000) (n +. lit 1)) In
+       {main = count (lit 1000) (lit 0)}
 \end{lstlisting}