Merge branch 'master' of git.martlubbers.net:msc-thesis1617
[msc-thesis1617.git] / conclusion.discussion.tex
index e5b10af..942ba83 100644 (file)
@@ -1,5 +1,6 @@
-The system is still a crude prototype and a proof of concept. Improvements and
-extension for the system are amply available in several fields of study.
+The novel system is functional but still a crude prototype and a proof of
+concept. The system shows potential but improvements and extensions for the
+system are amply available in several fields of study.
 
 \subsection{Simulation}
 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
@@ -18,7 +19,7 @@ peripheral input/output are more difficult to simulate properly.
 True multitasking could be added to the client software. This allows
 \gls{mTask}-\glspl{Task} to run truly parallel. All \gls{mTask}-\glspl{Task}
 get slices of execution time and will each have their own interpreter state
-instead of a single system-wide state which is reset after am \gls{mTask}
+instead of a single system-wide state which is reset after an \gls{mTask}
 finishes. This does require separate stacks for each \gls{Task} and therefore
 increases the system requirements of the client software. However, it could be
 implemented as a compile-time option and exchanged during the handshake so that
@@ -78,7 +79,8 @@ Adding this functionality to the bytecode-view allows greater flexibility,
 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