source: doc/theses/colby_parsons_MMAth/text/intro.tex @ 0f8b1a7

Last change on this file since 0f8b1a7 was 0f8b1a7, checked in by caparsons <caparson@…>, 9 months ago

merged in Peter's edits with a few small changes

  • Property mode set to 100644
File size: 6.9 KB
Line 
1% ======================================================================
2% ======================================================================
3\chapter{Introduction}\label{s:intro}
4% ======================================================================
5% ======================================================================
6
7Concurrent programs are the wild west of programming because determinism and simple ordering of program operations go out the window.
8To seize the reins and write performant and safe concurrent code, high-level concurrent-language features are needed.
9Like any other craftsmen, programmers are only as good as their tools, and concurrent tooling and features are no exception.
10
11This thesis presents a suite of high-level concurrent-language features implemented in the new programming-language \CFA.
12These features aim to improve the performance of concurrent programs, aid in writing safe programs, and assist user productivity by improving the ease of concurrent programming.
13The groundwork for concurrent features in \CFA was designed and implemented by Thierry Delisle~\cite{Delisle18}, who contributed the threading system, coroutines, monitors and other basic concurrency tools.
14This thesis builds on top of that foundation by providing a suite of high-level concurrent features.
15The features include a @mutex@ statement, channels, a @waituntil@ statement, and an actor system.
16All of these features exist in other programming languages in some shape or form;
17however, this thesis extends the original ideas by improving performance, productivity, and safety.
18
19\section{The Need For Concurrent Features}
20
21% Asking a programmer to write a complex concurrent program without any concurrent language features is asking them to undertake a very difficult task.
22% They would only be able to rely on the atomicity that their hardware provides and would have to build up from there.
23% This would be like asking a programmer to write a complex sequential program only in assembly.
24% Both are doable, but would often be easier and less error prone with higher level tooling.
25
26Concurrent programming has many unique pitfalls that do not appear in sequential programming:
27\begin{enumerate}
28\item Race conditions, where thread orderings can result in arbitrary behaviours, resulting in correctness problems.
29\item Livelock, where threads constantly attempt a concurrent operation unsuccessfully, resulting in no progress being made.
30\item Starvation, where \emph{some} threads constantly attempt a concurrent operation unsuccessfully, resulting in partial progress being made.
31\item Deadlock, where some threads wait for an event that cannot occur, blocking them indefinitely, resulting in no progress being made.
32\end{enumerate}
33Even with the guiding hand of concurrent tools these pitfalls still catch unwary programmers, but good language support helps significantly to prevent, detect, and mitigate these problems.
34
35\section{Thesis Overview}
36
37Chapter~\ref{s:cfa} of this thesis aims to familiarize the reader with the language \CFA.
38In this chapter, syntax and features of the \CFA language that appear in this work are discussed.
39Chapter~\ref{s:cfa_concurrency} briefly discusses prior concurrency work in \CFA, and how the work in this thesis builds on top of the existing framework.
40Each remaining chapter introduces an additional \CFA concurrent-language feature, which includes discussing prior related work for the feature, extensions over prior features, and uses benchmarks to compare the performance the feature with corresponding or similar features in other languages and systems.
41
42Chapter~\ref{s:mutexstmt} discusses the @mutex@ statement, a language feature that provides safe and simple lock usage.
43The @mutex@ statement is compared both in terms of safety and performance with similar mechanisms in \CC and Java.
44Chapter~\ref{s:channels} discusses channels, a message passing concurrency primitive that provides for safe synchronous and asynchronous communication among threads.
45Channels in \CFA are compared to Go's channels, which popularized the use of channels in modern concurrent programs.
46Chapter~\ref{s:actors} discusses the \CFA actor system.
47An actor system is a close cousin of channels, as it also belongs to the message passing paradigm of concurrency.
48However, an actor system provides a greater degree of abstraction and ease of scalability, making it useful for a different range of problems than channels.
49The actor system in \CFA is compared with a variety of other systems on a suite of benchmarks.
50Chapter~\ref{s:waituntil} discusses the \CFA @waituntil@ statement, which provides the ability to synchronize while waiting for a resource, such as acquiring a lock, accessing a future, or writing to a channel.
51The \CFA @waituntil@ statement provides greater flexibility and expressibility than similar features in other languages.
52All in all, the features presented aim to fill in gaps in the current \CFA concurrent-language support, enabling users to write a wider range of complex concurrent programs with ease.
53
54\section{Contributions}
55This work presents the following contributions within each of the additional language features:
56\begin{enumerate}[leftmargin=*]
57\item The @mutex@ statement that:
58    \begin{itemize}[itemsep=0pt]
59    \item
60    provides deadlock-free multiple lock acquisition,
61    \item
62    clearly denotes lock acquisition and release,
63    \item
64    and has good performance irrespective of lock ordering.
65    \end{itemize}
66\item The channel that:
67\begin{itemize}[itemsep=0pt]
68    \item
69    achieves comparable performance to Go, the gold standard for concurrent channels,
70    \item
71    has deadlock detection,
72    \item
73    introduces easy-to-use exception-based @close@ semantics,
74    \item
75    and provides toggle-able statistics for performance tuning.
76\end{itemize}
77\item The in-memory actor system that:
78\begin{itemize}[itemsep=0pt]
79    \item
80    achieves the lowest latency message send of all tested systems,
81    \item
82    is the first inverted actor system to introduce queue stealing,
83    \item
84    attains zero-victim-cost stealing through a carefully constructed stealing mechanism,
85    \item
86    gains performance through static-typed message sends, eliminating the need for dynamic dispatch,
87    \item
88    introduces the copy queue, an array-based queue specialized for the actor use-case to minimize calls to the memory allocator,
89    \item
90    has robust detection of six tricky, but common actor programming errors,
91    \item
92    achieves very good performance on a diverse benchmark suite compared to other actor systems,
93    \item
94    and provides toggle-able statistics for performance tuning.
95\end{itemize}
96\item The @waituntil@ statement that:
97\begin{itemize}[itemsep=0pt]
98    \item
99    is the only known polymorphic synchronous multiplexing language feature,
100    \item
101    provides greater expressibility for waiting conditions than other languages,
102    \item
103    and achieves comparable performance to similar features in two other languages.
104\end{itemize}
105\end{enumerate}
Note: See TracBrowser for help on using the repository browser.