source: doc/theses/colby_parsons_MMAth/text/CFA_concurrency.tex @ f3f009f

\chapter{Concurrency in \CFA}\label{s:cfa_concurrency}

The groundwork for concurrency in \CFA was laid by Thierry Delisle in his Master's Thesis~\cite{Delisle18}. 
In that work, he introduced generators, coroutines, monitors, and user-level threading. 
Not listed in that work were basic concurrency features needed as building blocks, such as locks, futures, and condition variables, which he also added to \CFA.

\section{Threading Model}\label{s:threading}
\CFA provides user-level threading and supports an $M$:$N$ threading model where $M$ user threads are scheduled on $N$ kernel threads, where both $M$ and $N$ can be explicitly set by the user. 
Kernel threads are created by declaring a @processor@ structure. 
User-thread types are defined by creating a @thread@ aggregate-type, \ie replace @struct@ with @thread@. 
For each thread type a corresponding @main@ routine must be defined, which is where the thread starts running once it is created. 
Examples of \CFA  user thread and processor creation are shown in \VRef[Listing]{l:cfa_thd_init}. 

\begin{cfa}[caption={Example of \CFA user thread and processor creation},label={l:cfa_thd_init}]
@thread@ my_thread {...};                       $\C{// user thread type}$
void @main@( my_thread & this ) {       $\C{// thread start routine}$
        sout | "Hello threading world";
}

int main() {
        @processor@ p[2];                               $\C{// add 2 processors = 3 total with starting processor}$
        {
                my_thread t[2], * t3 = new();   $\C{// create 3 user threads, running in main routine}$
                ... // execute concurrently
                delete( t3 );                           $\C{// wait for thread to end and deallocate}$
        } // wait for threads to end and deallocate
}
\end{cfa}

When processors are added, they are added alongside the existing processor given to each program. 
Thus, for $N$ processors, allocate $N-1$ processors. 
A thread is implicitly joined at deallocation, either implicitly at block exit for stack allocation or explicitly at @delete@ for heap allocation. 
The thread performing the deallocation must wait for the thread to terminate before the deallocation can occur. 
A thread terminates by returning from the main routine where it starts.

\section{Existing Concurrency Features}
\CFA currently provides a suite of concurrency features including futures, locks, condition variables, generators, coroutines, monitors.
Examples of these features are omitted as most of them are the same as their counterparts in other languages.
It is worthwhile to note that all concurrency features added to \CFA are made to be compatible each other.
The laundry list of features above and the ones introduced in this thesis can be used in the same program without issue.

Solving concurrent problems requires a diverse toolkit.
This work aims to flesh out \CFA's concurrent toolkit to fill in gaps.
Futures are used when a one-shot result needs to be safely delivered concurrently, and are especially useful when the receiver needs to block until the result is ready.
When multiple values have to be sent, or more synchronization is needed, futures are not powerful enough, which introduces the need for channels.
A close cousin of channels is actor systems, which take message passing a step further and go beyond channels to provide a level of abstraction that allows for easy scalability and separation of concerns.
The @waituntil@ and @mutex@ statements provide utilities allowing for easier use of the existing features.
All the contributions of this thesis provide the ability to solve concurrent problems that formerly would require a user to either implement a similar feature themselves or construct an ad-hoc solution.

% Local Variables: %
% tab-width: 4 %
% End: %