1 | % ====================================================================== |
---|
2 | % ====================================================================== |
---|
3 | \chapter{Conclusion}\label{s:conclusion} |
---|
4 | % ====================================================================== |
---|
5 | % ====================================================================== |
---|
6 | |
---|
7 | This thesis presented a suite of safe and efficient concurrency tools that provide users with the means to write scalable programs in \CFA through multiple avenues. |
---|
8 | If users prefer the message passing paradigm of concurrency, \CFA now provides message passing tools in the form of a performant actor system and channels. |
---|
9 | For shared memory concurrency, the mutex statement provides a safe and easy-to-use interface for mutual exclusion. |
---|
10 | The @waituntil@ statement aids in writing concurrent programs in both the message passing and shared memory paradigms of concurrency. |
---|
11 | Furthermore, no other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's @waituntil@. |
---|
12 | |
---|
13 | On overview of the contributions in this thesis include the following: |
---|
14 | \begin{enumerate} |
---|
15 | \item The mutex statement, which provides performant and deadlock-free multiple lock acquisition. |
---|
16 | \item Channels with comparable performance to Go, that have safety and productivity features including deadlock detection, and an easy-to-use exception-based channel @close@ routine. |
---|
17 | \item An in-memory actor system that achieved the lowest latency message send of systems tested due to the novel copy-queue data structure. The actor system presented has built-in detection of six common actor errors, and it has good performance compared to other systems on all benchmarks. |
---|
18 | \item A @waituntil@ statement which tackles the hard problem of allowing a thread to safely synch\-ronously wait for some set of concurrent resources. |
---|
19 | \end{enumerate} |
---|
20 | |
---|
21 | From the novel copy-queue data structure in the actor system and the plethora of user-supporting safety features, all these utilities build upon existing concurrent tooling with value added. |
---|
22 | Performance results verify that each new feature is comparable or better than similar features in other programming languages. |
---|
23 | All in all, this suite of concurrent tools expands users' ability to easily write safe and performant multi-threaded programs in \CFA. |
---|
24 | |
---|
25 | \section{Future Work} |
---|
26 | |
---|
27 | \subsection{Further Implicit Concurrency} |
---|
28 | |
---|
29 | This thesis only scratches the surface of implicit concurrency by providing an actor system. |
---|
30 | There is room for more implicit concurrency tools in \CFA. |
---|
31 | User-defined implicit concurrency in the form of annotated loops or recursive concurrent functions exists in many other languages and libraries~\cite{uC++,OpenMP}. |
---|
32 | Similar implicit concurrency mechanisms could be implemented and expanded on in \CFA. |
---|
33 | Additionally, the problem of automatic parallelism of sequential programs via the compiler is an interesting research space that other languages have approached~\cite{wilson94,haskell:parallel} and could be explored in \CFA. |
---|
34 | |
---|
35 | \subsection{Advanced Actor Stealing Heuristics} |
---|
36 | |
---|
37 | In this thesis, two basic victim-selection heuristics are chosen when implementing the work stealing actor system. |
---|
38 | Good victim selection is an active area of work stealing research, especially when taking into account NUMA effects and cache locality~\cite{barghi18,wolke17}. |
---|
39 | The actor system in \CFA is modular and exploration of other victim-selection heuristics for queue stealing in \CFA could be provided by pluggable modules. |
---|
40 | Another question in work stealing is: when should a worker thread steal? |
---|
41 | Work stealing systems can often be too aggressive when stealing, causing the cost of the steal to be have a negative rather positive effect on performance. |
---|
42 | Given that thief threads often have cycles to spare, there is room for a more nuanced approaches when stealing. |
---|
43 | Finally, there is the very difficult problem of blocking and unblocking idle threads for workloads with extreme oscillations in CPU needs. |
---|
44 | |
---|
45 | \subsection{Synchronously Multiplexing System Calls} |
---|
46 | |
---|
47 | There are many tools that try to synchronously wait for or asynchronously check I/O, since improvements in this area pay dividends in many areas of computer science~\cite{linux:select,linux:poll,linux:epoll,linux:iouring}. |
---|
48 | Research on improving user-space tools to synchronize over I/O and other system calls is an interesting area to explore in the world of concurrent tooling. |
---|
49 | Specifically, incorporating I/O into the @waituntil@ to allow a network server to work with multiple kinds of asynchronous I/O interconnects without using tradition event loops. |
---|
50 | |
---|
51 | \subsection{Better Atomic Operations} |
---|
52 | |
---|
53 | When writing low-level concurrent programs, especially lock/wait-free programs, low-level atomic instructions need to be used. |
---|
54 | In C, the gcc-builtin atomics~\cite{gcc:atomics} are commonly used, but leave much to be desired. |
---|
55 | Some of the problems include the following. |
---|
56 | Archaic and opaque macros often have to be used to ensure that atomic assembly is generated instead of locks. |
---|
57 | The builtins are polymorphic, but not type safe since they use void pointers. |
---|
58 | The semantics and safety of these builtins require careful navigation since they require the user to have a deep understanding of concurrent memory-ordering models. |
---|
59 | Furthermore, these atomics also often require a user to understand how to fence appropriately to ensure correctness. |
---|
60 | All these problems and more could benefit from language support in \CFA. |
---|
61 | Adding good language support for atomics is a difficult problem, which if solved well, would allow for easier and safer writing of low-level concurrent code. |
---|
62 | |
---|