1 | % ====================================================================== |
---|
2 | % ====================================================================== |
---|
3 | \chapter{Introduction}\label{s:intro} |
---|
4 | % ====================================================================== |
---|
5 | % ====================================================================== |
---|
6 | |
---|
7 | Concurrent programs are the wild west of programming because determinism and simple ordering of program operations go out the window. |
---|
8 | To seize the reins and write performant and safe concurrent code, high-level concurrent-language features are needed. |
---|
9 | Like any other craftsmen, programmers are only as good as their tools, and concurrent tooling and features are no exception. |
---|
10 | |
---|
11 | This thesis presents a suite of high-level concurrent-language features implemented in the new programming-language \CFA. |
---|
12 | These 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. |
---|
13 | The 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. |
---|
14 | This thesis builds on top of that foundation by providing a suite of high-level concurrent features. |
---|
15 | The features include a @mutex@ statement, channels, a @waituntil@ statement, and an actor system. |
---|
16 | All of these features exist in other programming languages in some shape or form; |
---|
17 | however, 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 | |
---|
26 | Concurrent 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} |
---|
33 | Even 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 | |
---|
37 | Chapter~\ref{s:cfa} of this thesis aims to familiarize the reader with the language \CFA. |
---|
38 | In this chapter, syntax and features of the \CFA language that appear in this work are discussed. |
---|
39 | Chapter~\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. |
---|
40 | Each 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 | |
---|
42 | Chapter~\ref{s:mutexstmt} discusses the @mutex@ statement, a language feature that provides safe and simple lock usage. |
---|
43 | The @mutex@ statement is compared both in terms of safety and performance with similar mechanisms in \CC and Java. |
---|
44 | Chapter~\ref{s:channels} discusses channels, a message passing concurrency primitive that provides for safe synchronous and asynchronous communication among threads. |
---|
45 | Channels in \CFA are compared to Go's channels, which popularized the use of channels in modern concurrent programs. |
---|
46 | Chapter~\ref{s:actors} discusses the \CFA actor system. |
---|
47 | An actor system is a close cousin of channels, as it also belongs to the message passing paradigm of concurrency. |
---|
48 | However, an actor system provides a greater degree of abstraction and ease of scalability, making it useful for a different range of problems than channels. |
---|
49 | The actor system in \CFA is compared with a variety of other systems on a suite of benchmarks. |
---|
50 | Chapter~\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. |
---|
51 | The \CFA @waituntil@ statement provides greater flexibility and expressibility than similar features in other languages. |
---|
52 | All 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} |
---|
55 | This 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} |
---|