From: Mart Lubbers <mart@martlubbers.net>
Date: Mon, 5 Dec 2016 17:56:48 +0000 (+0100)
Subject: update
X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=2a30e6c6088366a094db22ce5942a93b0fd757ac;p=ri1617.git

update
---

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.