\chapter{Finale}%
\label{chp:finale}
\begin{chapterabstract}
- This chapter wraps up the monograph by:
+ \noindent This chapter wraps up the monograph by means of:
\begin{itemize}
- \item providing a conclusion;
+ \item a conclusion;
+ \item an outlook on future work;
\item an overview of the related work;
- \item and giving a history of the \gls{MTASK} system.
+ \item and a history of the \gls{MTASK} system.
\end{itemize}
\end{chapterabstract}
\section{Finale}
-\todo[inline]{Conclusion}
+The \gls{MTASK} system is a proof-of-concept system, though fully functioning, for integrating \gls{IOT} edge devices in \gls{TOP}.
+In conjunction with \gls{ITASK}, it is possible to program all layers of the \gls{IOT} from a single declarative specification.
+
+\section{Future work}
+The \gls{MTASK} systems is a proof-of-concept system for integrating \gls{IOT} edge devices.
+
+Edge computing
+
+Intermittent computing
+
+Formal semantics
+
+Automatic peripherals
+
+Different architectures (FPGA?)
+
+Mesh communication
\section{Related work}
The novelties of the \gls{MTASK} system can be compared to existing systems in several categories.
However, the hardware requirements for running the standard \gls{HASKELL} system are high.
\subsection{Multi tasking}\label{sec:related_multi}
+Applications for tiny computers are often parallel in nature.
+Tasks like reading sensors, watching input devices, operating actuators and maintaining communication are often loosely dependent on each other and are preferably executed in parallel.
+Microcontrollers often do not benefit from an \gls{OS} due to memory and processing constraints.
+Therefore, writing multitasking applications in an imperative language is possible but the tasks have to be interleaved by hand \citep{feijs_multi-tasking_2013}.
+This results in hard to maintain, error prone and unscalable spaghetti code.
+
+There are many solutions to overcome this problem in imperative languages.
+
+If the host language is a functional language (e.g.\ the aforementioned scheme variants) multitasking can be achieved without this burden relatively easy using continuation style multiprocessing \citep{wand_continuation-based_1980}.
+Writing in this style is complicated and converting an existing program in this continuation passing style results in relatively large programs.
+Furthermore, there is no built-in thread-safe communication possible between the tasks.
+A \gls{TOP} or \gls{FRP} based language benefits even more because the programmer is not required to explicitly define continuation points.
+
+Regular preemptive multithreading is too memory intensive for smaller microcontrollers and therefore not suitable.
+Manual interleaving of imperative code can be automated to certain extents.
+Solutions often require an \gls{RTOS}, have a high memory requirement, do not support local variables, no thread-safe shared memory, no composition or no events as described in \cref{tbl:multithreadingcompare}.
+The table compares the solutions in the relevant categories with \gls{MTASK}.
+
+\begin{table}[ht]
+ \begin{threeparttable}
+ \caption{%
+ An overview of imperative multithreading solutions for tiny computers with their relevant characteristics.
+ The characteristics are: sequential execution, local variable support, parallel composition, deterministic execution, bounded execution and safe shared memory (adapted from \citet[p.\ 12]{santanna_safe_2013}).
+ }\label{tbl:multithreadingcompare}
+% \begin{tabular}{lc>{\columncolor[gray]{0.95}}cc>{\columncolor[gray]{0.95}}cc>{\columncolor[gray]{0.95}}cc}
+ \small
+ \begin{tabular}{lccccccc}
+ \toprule
+ \multicolumn{2}{c}{Language} & \multicolumn{3}{c}{Complexity} & \multicolumn{3}{c}{Safety}\\
+ \midrule
+ Name & Year & SeqCmp & LocVar & ParCmp & DetEx & BndEx & SafeMem\\
+ \midrule
+ Preemptive & many & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{} & rt & \Circle{}\\
+ nesC & 2003 & \Circle{} & \Circle{} & \Circle{} & \CIRCLE{} & async & \Circle{}\\
+ OSM & 2005 & \Circle{} & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{} & \Circle{}\\
+ Protothreads & 2006 & \CIRCLE{} & \Circle{} & \Circle{} & \CIRCLE{} & \Circle{} & \Circle{}\\
+ TinyThreads & 2006 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \CIRCLE{} & \Circle{} & \Circle{}\\
+ Sol & 2007 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{}\\
+ FlowTask & 2011 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{} & \Circle{} & \Circle{}\\
+ Ocram & 2013 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \CIRCLE{} & \Circle{} & \Circle{}\\
+ C\'eu & 2013 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{}\\
+ \Gls{MTASK} & 2022 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \LEFTcircle{}\tnote{1} & \LEFTcircle{}\tnote{2}\\
+ \bottomrule
+ \end{tabular}
+ \begin{tablenotes}
+ \item [1] Only for tasks, not for expressions.
+ \item [2] Using \glspl{SDS}.
+ \end{tablenotes}
+ \end{threeparttable}
+\end{table}
\section{History of \texorpdfstring{\gls{MTASK}}{mTask}}
The development of \gls{MTASK} or its predecessors has been going on for almost seven years now though it really set off during my master's thesis.
In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well \citep{lubbers_green_2022}.
Several students worked on extending \gls{MTASK} with many useful features:
\Citet{van_der_veen_mutable_2020} did preliminary work on a green computing analysis, built a simulator, and explored the possibilities for adding bounded datatypes; \citet{de_boer_secure_2020} investigated the possibilities for secure communication channels; \citeauthor{crooijmans_reducing_2021} \citeyearpar{crooijmans_reducing_2021,crooijmans_reducing_2022} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling; and \citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
+In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
\subsection*{\texorpdfstring{\gls{MTASK}}{mTask} in practise}
Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
-An existing smart campus application was developed using \gls{MTASK} and quantitively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
+An existing smart campus application was developed using \gls{MTASK} and quantitatively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2022}.
-Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a \gls{FREERTOS} implementation to the mix as well.
-
-\section{Future work}
-Plans for extensions and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; adding intermittent computing support to \gls{MTASK}; and extending the formal semantics to cover the entirety of the language.
-In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
+Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a \gls{FREERTOS}, and an elixer/potato implementation to the mix as well.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff