source: doc/proposals/concurrency/text/future.tex @ 64b272a

% ======================================================================
% ======================================================================
\chapter{Future Work}
% ======================================================================
% ======================================================================

\section{Flexible Scheduling} \label{futur:sched}


\section{Non-Blocking IO} \label{futur:nbio}
While most of the parallelism tools
However, many modern workloads are not bound on computation but on IO operations, an common case being webservers and XaaS (anything as a service). These type of workloads often require significant engineering around amortising costs of blocking IO operations. While improving throughtput of these operations is outside what \CFA can do as a language, it can help users to make better use of the CPU time otherwise spent waiting on IO operations. The current trend is to use asynchronous programming using tools like callbacks and/or futurs and promises\cit. However, while these are valid solutions, they lead to code that is harder to read and maintain because it is much less linear



\section{Other concurrency tools} \label{futur:tools}


\section{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 cannonical example of implcit parallelism is parallel for loops, which are the simplest example of a divide and conquer algorithm\cit. Listing \ref{lst:parfor} shows three different code examples that accomplish pointwise sums of large arrays. Note that none of these example explicitly declare any concurrency or parallelism objects.

\begin{figure}
\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{figure}

Implicit parallelism is a general solution and therefore is

\section{Multiple Paradigms} \label{futur:paradigms}


\section{Transactions} \label{futur:transaction}
Concurrency and parallelism is still a very active field that strongly benefits from hardware advances. As such certain features that aren't necessarily mature enough in their current state could become relevant in the lifetime of \CFA.