source: doc/proposals/concurrency/text/future.tex @ 8a62d04

\chapter{Conclusion}
As mentionned in the introduction, this thesis provides a minimal concurrency \acrshort{api} that is simple, efficient and usable as the basis for higher-level features. The approach presented is based on a lighweight thread system for parallelism which sits on top of clusters of processors. This M:N model is jugded to be both more efficient and allow more flexibility for users. Furthermore, this document introduces monitors as the main concurrency tool for users. This thesis also offers a novel approach which allows using multiple monitors at once without running into the Nested Monitor Problem~\cite{Lister77}. It also offers a full implmentation of the concurrency runtime wirtten enterily in \CFA, effectively the largest \CFA code base to date.


% ======================================================================
% ======================================================================
\section{Future Work}
% ======================================================================
% ======================================================================

\subsection{Performance} \label{futur:perf}
This thesis presents a first implementation of the \CFA runtime. Therefore, there is still significant work to do to improve performance. Many of the data structures and algorithms will change in the future to more efficient versions. For example, \CFA the number of monitors in a single \gls{bulk-acq} is only bound by the stack size, this is probably unnecessarily generous. It may be possible that limiting the number help increase performance. However, it is not obvious that the benefit would be significant.

\subsection{Flexible Scheduling} \label{futur:sched}
An important part of concurrency is scheduling. Different scheduling algorithm can affect performance (both in terms of average and variation). However, no single scheduler is optimal for all workloads and therefore there is value in being able to change the scheduler for given programs. One solution is to offer various tweaking options to users, allowing the scheduler to be adjusted to the requirements of the workload. However, in order to be truly flexible, it would be interesting to allow users to add arbitrary data and arbitrary scheduling algorithms to the scheduler. For example, a web server could attach Type-of-Service information to threads and have a ``ToS aware'' scheduling algorithm tailored to this specific web server. This path of flexible schedulers will be explored for \CFA.

\subsection{Non-Blocking IO} \label{futur:nbio}
While most of the parallelism tools are aimed at data parallelism and control-flow parallelism, many modern workloads are not bound on computation but on IO operations, a common case being web-servers and XaaS (anything as a service). These type of workloads often require significant engineering around amortizing costs of blocking IO operations. At its core, Non-Blocking IO is a operating system level feature that allows queuing IO operations (e.g., network operations) and registering for notifications instead of waiting for requests to complete. In this context, the role of the language make Non-Blocking IO easily available and with low overhead. The current trend is to use asynchronous programming using tools like callbacks and/or futures and promises, which can be seen in frameworks like Node.js~\cite{NodeJs} for JavaScript, Spring MVC~\cite{SpringMVC} for Java and Django~\cite{Django} for Python. However, while these are valid solutions, they lead to code that is harder to read and maintain because it is much less linear.

\subsection{Other concurrency tools} \label{futur:tools}
While monitors offer a flexible and powerful concurrent core for \CFA, other concurrency tools are also necessary for a complete multi-paradigm concurrency package. Example of such tools can include simple locks and condition variables, futures and promises~\cite{promises}, executors and actors. These additional features are useful when monitors offer a level of abstraction that is inadequate for certain tasks.

\subsection{Implicit threading} \label{futur:implcit}
Simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the library level. The canonical example of implicit parallelism is parallel for loops, which are the simplest example of a divide and conquer algorithm~\cite{uC++book}. Table \ref{lst:parfor} shows three different code examples that accomplish point-wise sums of large arrays. Note that none of these examples explicitly declare any concurrency or parallelism objects.

\begin{table}
\begin{center}
\begin{tabular}[t]{|c|c|c|}
Sequential & Library Parallel & Language Parallel \\
\begin{cfacode}[tabsize=3]
void big_sum(
        int* a, int* b,
        int* o,
        size_t len)
{
        for(
                int i = 0;
                i < len;
                ++i )
        {
                o[i]=a[i]+b[i];
        }
}





int* a[10000];
int* b[10000];
int* c[10000];
//... fill in a & b
big_sum(a,b,c,10000);
\end{cfacode} &\begin{cfacode}[tabsize=3]
void big_sum(
        int* a, int* b,
        int* o,
        size_t len)
{
        range ar(a, a+len);
        range br(b, b+len);
        range or(o, o+len);
        parfor( ai, bi, oi,
        [](     int* ai,
                int* bi,
                int* oi)
        {
                oi=ai+bi;
        });
}


int* a[10000];
int* b[10000];
int* c[10000];
//... fill in a & b
big_sum(a,b,c,10000);
\end{cfacode}&\begin{cfacode}[tabsize=3]
void big_sum(
        int* a, int* b,
        int* o,
        size_t len)
{
        parfor (ai,bi,oi)
            in (a, b, o )
        {
                oi = ai + bi;
        }
}







int* a[10000];
int* b[10000];
int* c[10000];
//... fill in a & b
big_sum(a,b,c,10000);
\end{cfacode}
\end{tabular}
\end{center}
\caption{For loop to sum numbers: Sequential, using library parallelism and language parallelism.}
\label{lst:parfor}
\end{table}

Implicit parallelism is a restrictive solution and therefore has its limitations. However, it is a quick and simple approach to parallelism, which may very well be sufficient for smaller applications and reduces the amount of boiler-plate needed to start benefiting from parallelism in modern CPUs.