source: doc/theses/colby_parsons_MMAth/text/intro.tex @ 1f10959

Last change on this file since 1f10959 was 1f10959, checked in by caparsons <caparson@…>, 10 months ago

expanded upon intro and conclusion

  • Property mode set to 100644
File size: 6.7 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 implemented by Thierry Delisle~\cite{Delisle18}, who contributed the threading system, coroutines, monitors and other 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, however this thesis extends the original ideas by improving performance, productivity, and safety.
17
18\section{The Need For Concurrent Features}
19Asking a programmer to write a complex concurrent program without any concurrent language features is asking them to undertake a very difficult task.
20They would only be able to rely on the atomicity that their hardware provides and would have to build up from there.
21This would be like asking a programmer to write a complex sequential program only in assembly.
22Both are doable, but would often be easier and less error prone with higher level tooling.
23
24Concurrent programming has many pitfalls that are unique and do not show up in sequential code:
25\begin{enumerate}
26\item Deadlock, where threads cyclically wait on resources, blocking them indefinitely.
27\item Livelock, where threads constantly attempt a concurrent operation unsuccessfully, resulting in no progress being made.
28\item Race conditions, where thread orderings can result in differing behaviours and correctness of a program execution.
29\item Starvation, where threads may be deprived of access to some shared resource due to unfairness and never make progress.
30\end{enumerate}
31Even with the guiding hand of concurrent tools these pitfalls can still catch unwary programmers, but good language support can prevent, detect, and mitigate these problems.
32
33\section{A Brief Overview}
34
35The first chapter of this thesis aims to familiarize the reader with the language \CFA.
36In this chapter, syntax and features of the \CFA language that appear in this work are discussed The next chapter briefly discusses prior concurrency work in \CFA and how this work builds on top of existing features.
37The remaining chapters each introduce a concurrent language feature, discuss prior related work, and present contributions which are then benchmarked against other languages and systems.
38The first of these chapters discusses the @mutex@ statement, a language feature that improves ease of use and safety of lock usage.
39The @mutex@ statement is compared both in terms of safety and performance with similar tools in \CC and Java.
40The following chapter discusses channels, a message passing concurrency primitive that provides an avenue for safe synchronous and asynchronous communication across threads.
41Channels in \CFA are compared to Go, which popularized the use of channels in modern concurrent programs.
42The following chapter discusses the \CFA actor system.
43The \CFA actor system is a close cousin of channels, as it also belongs to the message passing paradigm of concurrency.
44However, the actor system provides a great degree of abstraction and ease of scalability, making it useful for a different range of problems than channels.
45The actor system in \CFA is compared with a variety of other systems on a suite of benchmarks, where it achieves significant performance gains over other systems due to its design.
46The final chapter 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.
47The @waituntil@ statement presented provides greater flexibility and expressibility than similar features in other languages.
48All in all, the features presented aim to fill in gaps in the current \CFA concurrent language support, and enable users to write a wider range of complex concurrent programs with ease.
49
50\section{Contributions}
51This work presents the following contributions:
52\begin{enumerate}
53\item The @mutex@ statement which:
54\begin{itemize}[itemsep=0pt]
55\item
56provides deadlock-free multiple lock acquisition,
57\item
58clearly denotes lock acquisition and release,
59\item
60and has good performance irrespective of lock ordering.
61\end{itemize}
62\item Channels which:
63\begin{itemize}[itemsep=0pt]
64    \item
65    achieves comparable performance to Go, the gold standard for concurrent channels,
66    \item
67    has deadlock detection,
68    \item
69    introduces easy-to-use exception-based @close@ semantics,
70    \item
71    and provides toggle-able statistics for performance tuning.
72\end{itemize}
73\item An in-memory actor system that:
74\begin{itemize}[itemsep=0pt]
75    \item
76    achieves the lowest latency message send of all tested systems,
77    \item
78    is the first inverted actor system to introduce queue stealing,
79    \item
80    attains zero-victim-cost stealing through a carefully constructed stealing mechanism,
81    \item
82    gains performance through static-typed message sends, eliminating the need for dynamic dispatch,
83    \item
84    introduces the copy queue, an array based queue specialized for the actor use case to minimize calls to the memory allocator,
85    \item
86    has robust detection of six tricky, but common actor programming errors,
87    \item
88    achieves very good performance on a diverse benchmark suite compared to other actor systems,
89    \item
90    and provides toggle-able statistics for performance tuning.
91\end{itemize}
92
93\item A @waituntil@ statement which:
94\begin{itemize}[itemsep=0pt]
95    \item
96    is the only known polymorphic synchronous multiplexing language feature,
97    \item
98    provides greater expressibility of waiting conditions than other languages,
99    \item
100    and achieves comparable performance to similar features in two other languages,
101\end{itemize}
102\end{enumerate}
Note: See TracBrowser for help on using the repository browser.