From: Mart Lubbers 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]