paragraphs in future, update on shares
authorMart Lubbers <mart@martlubbers.net>
Wed, 21 Jun 2017 13:34:25 +0000 (15:34 +0200)
committerMart Lubbers <mart@martlubbers.net>
Wed, 21 Jun 2017 13:34:25 +0000 (15:34 +0200)
conclusion.tex
methods.dsl.tex
results.itasks.tex

index 0473625..e493a5b 100644 (file)
@@ -16,6 +16,7 @@ be simulated but timing and peripheral input/output are more difficult to
 simulate properly.
 
 \subsection{Optimization}
+\paragraph{Multitasking on the client:}
 True multitasking could be added to the client software. This allows
 \gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
 of execution time and will each have their own interpreter state instead of one
@@ -25,6 +26,7 @@ requirements of the client software. However, it could be implemented as a
 compile-time option and exchanged during the handshake so that the server knows
 the multithreading capabilities of the client.
 
+\paragraph{Optimizing the interpreter:}
 Hardly any work has been done in the interpreter. The current interpreter is a
 no nonsense stack machine. A lot of improvements can be done in this part. For
 example, precomputed \emph{gotos} can improve jumping to the correct part of
@@ -37,24 +39,27 @@ two-byte integers. Adding specialized instructions per word size could overcome
 this problem.
 
 \subsection{Resources}
+\paragraph{Resource analysis: }
 Resource analysis during compilation can be useful to determine if an
 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
 not contain the correct peripherals --- such as an \gls{LCD} --- then the
 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
 given. It might even be possible to do this statically on the type level.
 
-This idea could be extended to the analysis of stack size and possibly
+\paragraph{Extended resource analysis: }
+The previous idea could be extended to the analysis of stack size and possibly
 communication bandwidth. With this functionality ever more reliable fail-over
-systems can be designed. When the system knows precise bounds it can
-allocate more \glspl{Task} on a device whilst staying within safe memory
-bounds. The resource allocation can be done at runtime within the backend
-itself or a general backend can be devices that can calculate the resources
-needed for a given \gls{mTask}. A specific \gls{mTask} cannot have multiple
-views at the same time due to the restrictions of class based shallow
-embedding. It might even be possible to encode the resource allocation in the
-type system itself using forms of dependant types.
+systems can be designed. When the system knows precise bounds it can allocate
+more \glspl{Task} on a device whilst staying within safe memory bounds. The
+resource allocation can be done at runtime within the backend itself or a
+general backend can be devices that can calculate the resources needed for a
+given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
+same time due to the restrictions of class based shallow embedding. It might
+even be possible to encode the resource allocation in the type system itself
+using forms of dependant types.
 
 \subsection{Functionality}
+\paragraph{Add more combinators: }
 More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
 could be added to the \gls{mTask}-system to allow for more fine-grained control
 flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
@@ -63,6 +68,7 @@ flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
 mentioned extension such as the parallel combinator. Others might be achieved
 using simple syntactic transformations.
 
+\paragraph{Launch \glspl{Task} from a \gls{Task}: }
 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 server side. Adding
 this functionality to the bytecode-view allows greater flexibility, easier
@@ -71,7 +77,20 @@ modifications to the client software and extensions to the communication
 protocol since relations between \glspl{Task} also need to be encoded and
 communicated.
 
+The \gls{SDS} functionality in the current system is bare. There is no easy way
+of reusing a \gls{SDS} for another \gls{Task} on the same device or on another
+device. Such functionality can be implemented in a crude way by tying the
+\glspl{SDS} together in the \gls{iTasks} environment. However, this will result
+in a slow updating system. Functionality for reusing shares from a device
+should be added. This requires rethinking the storage because some typedness is
+lost when the \gls{SDS} is stored after compilation. A possibility would be to
+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 at paragraph~\ref{par:tasklaunch} is
+implemented.
+
 \subsection{Robustness}
+\paragraph{Reconnect with lost devices:}
 The robustness of the system can be greatly improved. Devices that lose
 connection are in the current system not well supported. The device will stop
 functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a
@@ -84,6 +103,7 @@ connection but keeps the \glspl{Task} in memory. During the downtime the
 same server connects to the client the delayed publications can be sent
 anyways.
 
+\paragraph{Reverse \gls{Task} sending:}
 Moreover, devices could send their current \glspl{Task} back at the
 server to synchronize it. This allows interchanging servers without
 interrupting the client. Allowing the client to send \glspl{Task} to the server
index 8304262..f21cb88 100644 (file)
@@ -142,7 +142,7 @@ instance intArith PrettyPrinter where
 Start :: (PP String, Bool)
 Start = (print e0, eval e0)
 where
-       e0 :: a Bool | intArith a &  boolArith a
+       e0 :: a Bool | intArith, boolArith a
        e0 = eq (lit 42) (lit 21 +. lit 21)
 
        print (PP p) = p
index a3ecffa..f7358a9 100644 (file)
@@ -1,8 +1,8 @@
-The server side of the system is written in \gls{iTasks}. Functions for managing
-devices, \glspl{Task} and \glspl{SDS} have been created to support the
-functionality. An interactive application has been created that
-allows an interactive management console for the \gls{mTask} system. This
-interface provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
+The server side of the system is written in \gls{iTasks}. Functions for
+managing devices, \glspl{Task} and \glspl{SDS} have been created to support the
+functionality. An interactive application has been created that allows an
+interactive management console for the \gls{mTask} system. This interface
+provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
 \glspl{Task}, administrate devices and view the state of the system.
 
 \section{Integration}
@@ -39,33 +39,43 @@ a device after a restart of the server application.
 \end{figure}
 
 \section{Shares}
-The architecture of the system stores the \glspl{SDS} in the \gls{SDS} that
-stores the list of devices. This means that if a \gls{SDS} updates, everyone
-watching it will be notified. This would result in to a lot of notifications
-that are not ment to be for the listener. Moreover, when a client updates the
-\gls{SDS} this is processed by the connection handler and results in an update
-of the real \gls{SDS}. When an \gls{iTasks}-\gls{Task} writes to a \gls{SDS}
-this is not passed on to the device.
-
-To solve the problem, parametric lenses are used on the device storage.
-Listing~\ref{lst:actualdev} shows the actual types for the device storage.
-Programmers wanting to access the entire \gls{SDS} use the \CI{deviceStoreNP}.
-Programmers wanting to access a single \gls{SDS} on a device can use the
-\CI{getRealShare} function which is a wrapper around the \CI{deviceStore} which
-applies a parametric lens to the \gls{SDS}.
+The architecture of the system needs to keep track of the \glspl{SDS} stored on
+the client. \glspl{SDS} can be stored on only one device at the same time.
+that also stores the of devices. This means that if a \gls{SDS} updates,
+everyone watching it will be notified. This would result in to a lot of
+notifications that are not ment to be for the listener. Moreover, when a client
+updates the \gls{SDS} this is processed by the connection handler and results
+in an update of the real \gls{SDS}.
+Finally, the \gls{SDS} of a client must be synchronized with the actual device.
+There are several ways of tackling this problem each with their own pros and
+cons and their own level of abstraction.
+
+\begin{itemize}
+       \item Instantiate an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used
+               in a client.
+
+
+       \item Instantiate a \gls{iTasks}-\gls{SDS} for every device that stores all
+               their \glspl{SDS}.
+
+       \item Use only one \gls{iTasks}-\gls{SDS} for all devices.
+\end{itemize}
 
 \begin{lstlisting}[label={lst:actualdev},%
        caption={Real types for the device \gls{SDS}}]
 deviceStoreNP :: Shared [MTaskDevice]
 deviceStore :: RWShared (Maybe (MTaskDevice, Int)) [MTaskDevice] [MTaskDevice]
-
-realDeviceStore :: Shared [MTaskDevice]
-
-getRealShare :: MTaskDevice MTaskShare -> Shared BCValue
 \end{lstlisting}
 
 \subsection{Parametric Lens}
-The type of the parametric lens is \CI{Maybe (MTaskDevice, Int)} where the
+The type of the parametric lens is \CI{Maybe (MTaskDevice, Int)}. The \gls{SDS}
+can either be focussed on the entire share, from now on global. Moreover, the
+\gls{SDS} can focus on a single device, from now on local. A local \gls{SDS}
+can also specifically focus on a single \gls{SDS} on a single device.
+
+The implementation for the share is shown in Listing~\ref{lst:shareimpl}. The
+\CI{realDeviceStore} \gls{SDS} is not exported through the header files. This
+\gls{SDS} contains the actual \gls{SDS} that writes to disk or memory.
 \CI{Int} is the identifier of the \gls{SDS}. The \gls{iTasks} way of applying
 lenses is through the \CI{sdsFocus} function and through the \CI{sdsLens}
 functions. \CI{sdsFocus} allows the programmer to fix the parameter.