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

\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.

\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 and both $M$ and $N$ can be explicitly set by the programmer.
Kernel threads are created by declaring processor objects;
user threads are created by declaring a thread objects.
\VRef[Listing]{l:cfa_thd_init} shows a typical examples of creating a \CFA user-thread type, and then as declaring processor ($N$) and thread objects ($M$).
\begin{cfa}[caption={Example of \CFA user thread and processor creation},label={l:cfa_thd_init}]
@thread@ my_thread {                            $\C{// user thread type (like structure)}$
        ... // arbitrary number of field declarations
};
void @main@( @my_thread@ & this ) {     $\C{// thread start routine}$
        sout | "Hello threading world";
}
int main() {                                            $\C{// program starts with a processor (kernel thread)}$
        @processor@ p[2];                               $\C{// add 2 processors = 3 total with starting processor}$
        {
                @my_thread@ t[2], * t3 = new(); $\C{// create 2 stack allocated, 1 dynamic allocated user threads}$
                ... // execute concurrently
                delete( t3 );                           $\C{// wait for t3 to end and deallocate}$
    } // wait for threads t[0] and t[1] to end and deallocate
} // deallocate additional kernel threads
\end{cfa}
A thread type is are defined using the aggregate kind @thread@.
For each thread type, a corresponding @main@ routine must be defined, which is where the thread starts running once when a thread object are is created.
The @processor@ declaration adds addition kernel threads 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 and New 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, and the features are designed to interact in meaningful ways.
For example, a thread can inteact with a monitor, which can interact with a coroutine, which can interact with a generator.

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: %