From: Mart Lubbers <mart@martlubbers.net>
Date: Thu, 29 Jun 2017 11:56:34 +0000 (+0200)
Subject: elaborated on task and share storage
X-Git-Tag: hand-in~36^2~1
X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=cbbebee89b5cc3da0455308e51f92311b67be3a5;p=msc-thesis1617.git

elaborated on task and share storage
---

diff --git a/results.arch.tex b/results.arch.tex
index 2d6f531..0164945 100644
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -113,20 +113,38 @@ device.
 \end{algorithm}
 
 \subsubsection{Storage}
-\glspl{Task} and \glspl{SDS} are stored on the client in one big memory space
-that is reserved at the start of the program. The space could also have been
-dynamically allocated but that would require using the heap which is unwanted
-in small memory environments. \Glspl{Task} grow from the bottom up and
-\glspl{SDS} grow from the top down. When a \gls{Task} or \gls{SDS} is removed,
-all \glspl{Task} residing in higher areas of the memory are relocated in the
-memory space to not leave holes. Both \glspl{Task} and \glspl{SDS} are stored
-as structures that are linked in the memory space, helper functions are
-available to loop through them without having to fiddle in the memory space
-itself. The instances for \glspl{Task} and \glspl{SDS} are shown in
-Listing~\ref{lst:structs} accompanied by the helper functions for \glspl{Task}.
-\Glspl{Task} consists of the length, interval, last run time, id and the
-bytecode. \Glspl{SDS} consist only of an id, value and type. The pointer to the
-bytecode of the \gls{Task} always points to the location in the memory space.
+\glspl{Task} and \glspl{SDS} are stored on the client in memory. Some devices
+have very little memory and therefore memory space is very expensive and needs
+to be used optimally. Almost all microcontrollers support heaps nowadays,
+however, the functions for allocating and freeing the memory on the heap are
+not very space optimal and often leave holes in the heap if allocations are not
+freed in reverse order. To overcome this problem the client will allocate a big
+memory segment in the global data block. This block of memory resides under the
+stack and its size can be set in the interface implementation. This block of
+memory will be managed in a similar way as the entire memory space of the
+device is managed. \Glspl{Task} will grow from the bottom up and \glspl{SDS}
+will grow from the top down.
+
+When a \gls{Task} is received, the program will traverse the memory space from
+the bottom up, jumping over all \glspl{Task}. A \gls{Task} is stored as the
+structure followed directly by its bytecode. Therefore it only takes two jumps
+to determine the size of the \gls{Task}. When the program arrived at the last
+\gls{Task}, this place is returned and the newly received \gls{Task} can be
+copied to there. This method is analogously applied for \glspl{SDS}, however,
+the \glspl{SDS} grow from the bottom down.
+
+When a \gls{Task} or \gls{SDS} is removed, all remaining objects are compressed
+again. This means that if the first received \gls{Task} is removed, all
+\glspl{Task} received later will have to move back. Obviously, this is quite
+time intensive but it can not be permitted to leave holes in the memory since
+the memory space is so limited. This techniques allows for even the smallest
+tested microcontrollers with only $2K$ \emph{RAM} to hold several \glspl{Task}
+and \glspl{SDS}. If this technique would not be used the memory space will
+decrease over time and the client can then not run for very long since holes
+are evidently created at some point.
+
+The structure instances and helper functions for traversing them in memory for
+\glspl{Task} and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
 
 \begin{lstlisting}[language=C,label={lst:structs},%
 	caption={The data type storing the \glspl{Task}},float]