conclusion.discussion.tex

   1 The novel system is functional but still a crude prototype and a proof of
   2 concept. The system shows potential but improvements and extensions for the
   3 system are amply available in several fields of study.
   4
   5 \subsection{Simulation}
   6 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
   7 works in the same way as the existing \gls{C}-backed simulation. It simulates
   8 the bytecode interpretation. Moreover, it would also be possible to let the
   9 simulator function as a real device, thus handling all communication through
  10 the existing \gls{SDS}-based systems. At the moment the \emph{POSIX}-client is
  11 the reference client and contains debugging code.  Adding a simulation view to
  12 the system allows for easy interactive debugging.  However, it might not be
  13 easy to devise a simulation tool that accurately simulates the \gls{mTask}
  14 system on some levels. The execution strategy can be simulated but timing and
  15 peripheral input/output are more difficult to simulate properly.
  16
  17 \subsection{Optimization}
  18 \paragraph{Multitasking on the client:}
  19 True multitasking could be added to the client software. This allows
  20 \gls{mTask}-\glspl{Task} to run truly parallel. All \gls{mTask}-\glspl{Task}
  21 get slices of execution time and will each have their own interpreter state
  22 instead of a single system-wide state which is reset after an \gls{mTask}
  23 finishes. This does require separate stacks for each \gls{Task} and therefore
  24 increases the system requirements of the client software. However, it could be
  25 implemented as a compile-time option and exchanged during the handshake so that
  26 the server knows the multithreading capabilities of the client. Multithreading
  27 allows \glspl{Task} to be truly interruptible by other \glspl{Task}.
  28 Furthermore, this allows for more fine-grained timing control of \glspl{Task}.
  29
  30 \paragraph{Optimizing the interpreter:}
  31 Due to time constraints and focus, hardly any work has been done in the
  32 interpreter. The current interpreter is a no nonsense stack machine. A lot of
  33 improvements can be done in this part. For example, precomputed \emph{gotos}
  34 can improve jumping to the correct part of the code corresponding to the
  35 correct instruction.  Moreover, the stack currently consists of 16-bit values.
  36 All operations work on 16-bit values and this simplifies the interpreter
  37 implementation. A memory improvement can be made by converting the stack to
  38 8-bit values. This does pose some problems since an equality instruction must
  39 work on single-byte booleans \emph{and} two-byte integers. Adding specialized
  40 instructions per word size could overcome this problem.
  41
  42 \subsection{Resources}
  43 \paragraph{Resource analysis: }
  44 Resource analysis during compilation can be useful to determine if an
  45 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
  46 not contain the correct peripherals --- such as an \gls{LCD} --- then the
  47 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
  48 given. It might even be possible to do this statically on the type level. The
  49 current system does not have any of this built-in. Sending a \gls{Task} that
  50 uses the \gls{LCD} to a device not containing one will result in the device
  51 just skipping the \gls{LCD} related instructions.
  52
  53 \paragraph{Extended resource analysis: }
  54 The previous idea could be extended to the analysis of stack size and possibly
  55 communication bandwidth. With this functionality ever more reliable fail-over
  56 systems can be designed. When the system knows precise bounds it can allocate
  57 more \glspl{Task} on a device whilst staying within safe memory bounds. The
  58 resource allocation can be done at runtime within the backend itself or a
  59 general backend can be devised that can calculate the resources needed for a
  60 given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
  61 same time due to the restrictions of class based shallow embedding. It might
  62 even be possible to encode the resource allocation in the type system itself
  63 using forms of dependant types.
  64
  65 \subsection{Functionality}
  66 \paragraph{Add more combinators: }
  67 More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
  68 could be added to the \gls{mTask}-system to allow for more fine-grained control
  69 flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
  70 \gls{TOP} paradigm even more and makes programming \gls{mTask}-\glspl{Task} for
  71 \gls{TOP}-programmers more seamless. Some of the combinators require previously
  72 mentioned extension such as the parallel combinator. Others might be achieved
  73 using simple syntactic transformations.
  74
  75 \paragraph{Launch \glspl{Task} from a \gls{Task}:}
  76 Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
  77 the current system this type of logic has to take place on the server side.
  78 Adding this functionality to the bytecode-view allows greater flexibility,
  79 easier programming and less communication resources. Adding this type of
  80 scheduling requires modifications to the client software and extensions to the
  81 communication protocol since relations between \glspl{Task} also need to be
  82 encoded and communicated. A similar technique as used with \glspl{SDS} has to
  83 be used to overcome the scoping problem.
  84
  85 The \gls{SDS} functionality in the current system is bare. There is no easy way
  86 of reusing an \gls{SDS} for another \gls{Task} on the same device or on another
  87 device. Such functionality can be implemented in a crude way by tying the
  88 \glspl{SDS} together in the \gls{iTasks} environment. However, this will result
  89 in a slow updating system. Functionality for reusing shares from a device
  90 should be added. This requires rethinking the storage because some typedness is
  91 lost when the \gls{SDS} is stored after compilation. A possibility would be to
  92 use runtime typing with \CI{Dynamic}s or the encoding technique currently used
  93 for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one
  94 device is solved when the previous point is implemented.
  95
  96 Another way of improving on \gls{SDS} handling is to separate \glspl{SDS} from
  97 devices. In this implementation, the \gls{SDS} not only needs to know on which
  98 device it is, but also which internal device \gls{SDS} id it has. A pro of
  99 this technique is that the \gls{SDS} can be shared between \glspl{Task} that
 100 are not defined in the same scope because they are separated. A con of this
 101 implementation is that the mechanisms for implementing \glspl{SDS} have to be
 102 more complex, they have to keep track of the devices containing or sharing an
 103 \gls{SDS}. Moreover, when the \gls{SDS} is updated, all attached devices must
 104 be updated which requires some extra work.
 105
 106 \subsection{Robustness}
 107 \paragraph{Reconnect with lost devices:}
 108 The robustness of the system can be greatly improved. Devices that lose
 109 connection are not well supported in the current system. The device will stop
 110 functioning and has to be emptied for a reconnect. \Glspl{Task} residing on a
 111 device that disconnected should be kept on the server to allow a swift
 112 reconnect and restoration of the \glspl{Task}. This holds the same for the
 113 client software. The client drops all existing \glspl{Task} on a shutdown
 114 request. An extra specialization of the shutdown could be added that drops the
 115 connection but keeps the \glspl{Task} in memory. During the downtime the
 116 \glspl{Task} can still be executed but publications need to be delayed. If the
 117 same server connects to the client the delayed publications can be sent
 118 anyways.
 119
 120 \paragraph{Reverse \gls{Task} sending:}
 121 Furthermore, devices could send their current \glspl{Task} back to the
 122 server to synchronize it. This allows interchanging servers without
 123 interrupting the client. Allowing the client to send \glspl{Task} to the server
 124 is something to handle with care because it can easily cause high bandwidth
 125 usage.