From 2a30e6c6088366a094db22ce5942a93b0fd757ac Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 5 Dec 2016 18:56:48 +0100 Subject: [PATCH] update --- architecture/Makefile | 3 +-- architecture/a.tex | 6 +++--- architecture/itasks.tex | 43 +++++++++++++++++++++++++++++++++++++---- 3 files changed, 43 insertions(+), 9 deletions(-) diff --git a/architecture/Makefile b/architecture/Makefile index 5c749ac..8d02b02 100644 --- a/architecture/Makefile +++ b/architecture/Makefile @@ -14,8 +14,7 @@ all: $(DOC).pdf $(LATEX) $(LATEXFLAGS) -ini -jobname="$(basename $@)" "&$(LATEX) $<\dump" %.pdf: %.mlog - grep -qF 'Please rerun LaTeX.' $(basename $<).mlog &&\ - $(LATEX) $(LATEXFLAGS) $< || true + grep -qiF 'rerun' $< && $(LATEX) $(LATEXFLAGS) $(basename $<) || true %.mlog: %.tex %.fmt %.bib $(TEXS) $(LATEX) $(LATEXFLAGS) $< diff --git a/architecture/a.tex b/architecture/a.tex index 32f0924..3f11f02 100644 --- a/architecture/a.tex +++ b/architecture/a.tex @@ -21,6 +21,9 @@ \subsection{Bytecode specification} \todo{Bytecode specificatie} +\subsection{\iTasks{}} +\input{itasks.tex} + \subsection{Communication} We can divide the communication up into two parts. Communication from the \iTasks{} server to the microcontroller and vice versa. The means of @@ -36,9 +39,6 @@ resources. \subsubsection{Microcontroller $\rightarrow$ \iTasks{}} \input{commmi.tex} -\subsection{\iTasks{} task} -\input{itasks.tex} - \section{Conclusion} \input{conclusion.tex} diff --git a/architecture/itasks.tex b/architecture/itasks.tex index 98683e7..acc5da1 100644 --- a/architecture/itasks.tex +++ b/architecture/itasks.tex @@ -1,4 +1,27 @@ \subsubsection{\iTasks{} task} +\mTask{}s are no regular tasks in the sense that they can be combined with task +combinators. Moreover \mTask{}s can not communicate directly with each other or +with the server. Indirect communication is possible through a special type of +SDSs that lives solely within the mother task and the microcontroller. + +An \mTask{} controller is just another \iTasks{} task and can be instantiated. +The controller task will manage the devices and keep track of the data +structures. + +Devices can be added to the controller by giving a specification of the +communication and some properties of the device. Not all devices are the same +so a data structure containing properties will have to be devised. + +An \mTask{} can be added through the \CI{runmTask} function that from a given +\mTask{} returns a \CI{Task Int}. The \CI{Int} denotes the unique identifier of +the task that can later on be used to kill a task even when it is not finished. +During initialization the task value is \CI{NoValue}. When the initialization +is done and the task is loaded the value becomes an unstable \CI{Int} value +that denotes the task identification. When the task is finished the value +becomes stable and no interaction can be done with the type from then on. + +\todo{Dit wat hieronder staat omschrijven} + To make the integration of \mTask{}s in \iTasks{} more orthogonal we need a special kind of task that serves as a mothertask that has the type visible in Listing~\ref{lst:mothertask}. At first the system must be initialized with the @@ -19,8 +42,20 @@ delmTask :: Int -> Task Bool \subsubsection{Shared Data Sources} \mTask{}s can use SDSs for means of storing information and for communicating -with the server. Communication can be slow and therefore SDSs are only updated -when a task specifically asks for it through the bytecode instructions for -publishing and getting SDS values. +back to the server. Communication can be slow and therefore SDSs are only +updated when a task specifically asks for it through the bytecode instructions +for publishing and getting SDS values. This means that the SDS functions a +little different from SDSs used in general \iTasks{} in the sense that they can +run out of sync. For now we solve this by giving the \mTask{} system priority +and adhering to his store. In practise this means that it is not mandatory to +first fetch the latest SDS value before updateing and possibly publishing it. +The responsibility lies with the programmer when such behaviour is necessary. -\todo{Uitleg over synchronisatie als de sds op de server veranderd} +The mothertask manages the SDSs per device. This means that it is not possible +in principle to have one SDS shared over multiple devices. This does not mean +that it is not possible at all. With a suitable task doing the synchronization +one can realize this functionality. SDSs also never leave the domain of the +mothertask. It is not possible to use an existing SDS for the purpose of an +\mTask{}, SDSs used in \mTask{} are always instantiated on the fly to prevent +confusion and race conditions on the data. This results in the following +situation. -- 2.20.1