X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=conclusion.discussion.tex;h=90a91d3e7377e8c3b1e02986b6492b0338e031bb;hb=2498dced580be1e7af31a662dadee26c4fd159ed;hp=3b1657ffaf595e2bff640613e05d31b224479702;hpb=6548a5ec9ce8e0df67fc4019625ab5238eb1bf71;p=msc-thesis1617.git

diff --git a/conclusion.discussion.tex b/conclusion.discussion.tex
index 3b1657f..90a91d3 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,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
@@ -91,6 +92,16 @@ use runtime typing with \CI{Dynamic}s or the encoding technique currently used
 for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one
 device is solved when the previous point is implemented.
 
+Another way of improving on \gls{SDS} handling is to separate \glspl{SDS} from
+devices. In this implementation, the \gls{SDS} not only needs to know on which
+device it is, but also which internal device \gls{SDS} id it has. A pro of
+this technique is that the \gls{SDS} can be shared between \glspl{Task} that
+are not defined in the same scope because they are separated. A con of this
+implementation is that the mechanisms for implementing \glspl{SDS} have to be
+more complex, they have to keep track of the devices containing or sharing an
+\gls{SDS}. Moreover, when the \gls{SDS} is updated, all attached devices must
+be updated which requires some extra work.
+
 \subsection{Robustness}
 \paragraph{Reconnect with lost devices:}
 The robustness of the system can be greatly improved. Devices that lose