update presentation, the body is there

[msc-thesis1617.git] / conclusion.discussion.tex

diff --git a/conclusion.discussion.tex b/conclusion.discussion.tex
index 2bd77d3..90a91d3 100644 (file)
--- 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,10 +75,11 @@ 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.
+encoded and communicated. A similar technique as used with \glspl{SDS} has to
+be used to overcome the scoping problem.
 
 The \gls{SDS} functionality in the current system is bare. There is no easy way
 of reusing an \gls{SDS} for another \gls{Task} on the same device or on another