From 78d08778c999d9bb644b76e4c8dd1a248917429f Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Thu, 29 Jun 2017 13:22:08 +0200 Subject: [PATCH] process rinus' textual comments on chp5-7 --- results.arch.tex | 36 ++++++++++++++++++------------------ results.mtask.tex | 22 +++++++++++----------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/results.arch.tex b/results.arch.tex index b6b0b3d..2d6f531 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -14,9 +14,9 @@ The following terms will be used throughout the following chapter: \begin{itemize} \item Device, Client - These terms denotes the actual device connected to the system. This can be a - real device such as a microcontroller but it can also just be a program - on the same machine as the server functioning as a client. + These terms denotes the actual device connected to the system. This can + be a real device such as a microcontroller but it can also just be a + program on the same machine as the server functioning as a client. \item Server, \gls{iTasks}-System This is the actual executable serving the \gls{iTasks} application. The @@ -75,13 +75,13 @@ the device software. \subsection{Client} \subsubsection{Engine} The client is in a constant loop listening for input and waiting to execute -\gls{Task}. The pseudocode for this is shown in Algorithm~\ref{alg:client}. The -\CI{input\_available} function waits for input, but has a timeout set which can -be interrupted. The timeout of the function determines the amount of loops per -time interval and is a parameter that can be set during compilation for a +\glspl{Task}. The pseudocode for this is shown in Algorithm~\ref{alg:client}. +The \CI{input\_available} function waits for input, but has a timeout set which +can be interrupted. The timeout of the function determines the amount of loops +per time interval and is a parameter that can be set during compilation for a device. -\begin{algorithm}[H] +\begin{algorithm} \KwData{ \textbf{list} $tasks$, \textbf{time} $t$ @@ -129,7 +129,7 @@ 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. \begin{lstlisting}[language=C,label={lst:structs},% - caption={The data type storing the \glspl{Task}}] + caption={The data type storing the \glspl{Task}},float] struct task { uint16_t tasklength; uint16_t interval; @@ -245,15 +245,15 @@ types. | SerialDevice TTYSettings | ... :: MTaskDevice = - { deviceTask :: Maybe TaskId - , deviceError :: Maybe String + { deviceTask :: Maybe TaskId + , deviceError :: Maybe String , deviceChannels :: String - , deviceName :: String - , deviceState :: BCState - , deviceTasks :: [MTaskTask] - , deviceData :: MTaskResource - , deviceSpec :: Maybe MTaskDeviceSpec - , deviceShares :: [MTaskShare] + , deviceName :: String + , deviceState :: BCState + , deviceTasks :: [MTaskTask] + , deviceResource :: MTaskResource + , deviceSpec :: Maybe MTaskDeviceSpec + , deviceShares :: [MTaskShare] } channels :: MTaskDevice -> Shared Channels @@ -595,7 +595,7 @@ server application. {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}} If the user does not want to know where and when a \gls{mTask} is actually executed and is just interested in the results it can lift the \gls{mTask} to -an \gls{iTasks}-\glspl{Task}. The function is called with a name, \gls{mTask}, +an \gls{iTasks}-\gls{Task}. The function is called with a name, \gls{mTask}, device and interval specification and it will return a \gls{Task} that finishes if and only if the \gls{mTask} has returned. diff --git a/results.mtask.tex b/results.mtask.tex index acc6a69..6ec25a4 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -38,18 +38,18 @@ reflected in the \CI{MTTask} message type. \end{itemize} \section{\gls{SDS} semantics} -\Glspl{SDS} on a client are available on the server as well as regular -\glspl{SDS}. However, the same freedom is not given for \glspl{SDS} that +\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form +of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an +\gls{SDS} has in the \gls{iTasks}-system is not given for \glspl{SDS} that reside on the client. Not all types are suitable to be located on a client, -simply because it needs to be representable on clients. -Moreover, \glspl{SDS} behave a little different in an \gls{mTask} device -compared to in the \gls{iTasks} system. In an \gls{iTasks} system, when the -\gls{SDS} is updated, a broadcast to all watching \glspl{Task} in the system -is made to notify them of the update. \glspl{SDS} can update often and the -update might not be the final value it will get. Implementing the same -functionality on the \gls{mTask} client would result in a lot of expensive -unneeded bandwidth usage. Therefore a device must publish the \gls{SDS} -explicitly to save bandwidth. +simply because it needs to be representable on clients. Moreover, \glspl{SDS} +behave a little different in an \gls{mTask} device compared to in the +\gls{iTasks} system. In an \gls{iTasks} system, when the \gls{SDS} is updated, +a broadcast to all watching \glspl{Task} in the system is made to notify them +of the update. \glspl{SDS} can update often and the update might not be the +final value it will get. Implementing the same functionality on the \gls{mTask} +client would result in a lot of expensive unneeded bandwidth usage. Therefore +a device must publish the \gls{SDS} explicitly to save bandwidth. To add this functionality, the \CI{sds} class could be extended. However, this would result in having to update all existing views that use the \CI{sds} -- 2.20.1