1 | % ====================================================================== |
---|
2 | % ====================================================================== |
---|
3 | \chapter{Conclusion}\label{s:conclusion} |
---|
4 | % ====================================================================== |
---|
5 | % ====================================================================== |
---|
6 | |
---|
7 | The goal of this thesis was to expand the concurrent support that \CFA offers to fill in gaps and support language users' ability to write safe and efficient concurrent programs. |
---|
8 | The presented features achieves this goal, and provides users with the means to write scalable programs in \CFA through multiple avenues. |
---|
9 | Additionally, the tools presented include safety and productivity features from deadlock detection, to detection of common programming errors, easy concurrent shutdown, and toggleable performance statistics. |
---|
10 | Programmers often have preferences between computing paradigms and concurrency is no exception. |
---|
11 | If users prefer the message passing paradigm of concurrency, \CFA now provides message passing utilities in the form of an actor system and channels. |
---|
12 | For shared memory concurrency, the mutex statement provides a safe and easy-to-use interface for mutual exclusion. |
---|
13 | The @waituntil@ statement aids in writing concurrent programs in both the message passing and shared memory paradigms of concurrency. |
---|
14 | Furthermore, no other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's @waituntil@. |
---|
15 | This work successfully provides users with familiar concurrent language support, but with additional value added over similar utilities in other popular languages. |
---|
16 | |
---|
17 | On overview of the contributions in this thesis include the following: |
---|
18 | \begin{enumerate} |
---|
19 | \item The mutex statement, which provides performant and deadlock-free multiple lock acquisition. |
---|
20 | \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. |
---|
21 | \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. |
---|
22 | \item A @waituntil@ statement which tackles the hard problem of allowing a thread to safely synch\-ronously wait for some set of concurrent resources. |
---|
23 | \end{enumerate} |
---|
24 | |
---|
25 | The features presented are commonly used in conjunction to solve concurrent problems. |
---|
26 | The @waituntil@ statement, the @mutex@ statement, and channels will all likely see use in a program where a thread operates as an administrator or server which accepts and distributes work among channels based on some shared state. |
---|
27 | The @mutex@ statement sees use across almost all concurrent code in \CFA, since it is used with the stream operator @sout@ to provide thread-safe output. |
---|
28 | While not yet implemented, the polymorphic support of the @waituntil@ statement could see use in conjunction with the actor system to enable user threads outside the actor system to wait for work to be done, or for actors to finish. |
---|
29 | A user of \CFA does not have to solely subscribe to the message passing or shared memory concurrent paradigm. |
---|
30 | As such, channels in \CFA are often used to pass pointers to shared memory that may still need mutual exclusion, requiring the @mutex@ statement to also be used. |
---|
31 | |
---|
32 | 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. |
---|
33 | Performance results verify that each new feature is comparable or better than similar features in other programming languages. |
---|
34 | All in all, this suite of concurrent tools expands users' ability to easily write safe and performant multi-threaded programs in \CFA. |
---|
35 | |
---|
36 | \section{Future Work} |
---|
37 | |
---|
38 | \subsection{Further Implicit Concurrency} |
---|
39 | |
---|
40 | This thesis only scratches the surface of implicit concurrency by providing an actor system. |
---|
41 | There is room for more implicit concurrency tools in \CFA. |
---|
42 | User-defined implicit concurrency in the form of annotated loops or recursive concurrent functions exists in many other languages and libraries~\cite{uC++,OpenMP}. |
---|
43 | Similar implicit concurrency mechanisms could be implemented and expanded on in \CFA. |
---|
44 | 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. |
---|
45 | |
---|
46 | \subsection{Advanced Actor Stealing Heuristics} |
---|
47 | |
---|
48 | In this thesis, two basic victim-selection heuristics are chosen when implementing the work stealing actor system. |
---|
49 | Good victim selection is an active area of work stealing research, especially when taking into account NUMA effects and cache locality~\cite{barghi18,wolke17}. |
---|
50 | 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. |
---|
51 | Another question in work stealing is: when should a worker thread steal? |
---|
52 | 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. |
---|
53 | Given that thief threads often have cycles to spare, there is room for a more nuanced approaches when stealing. |
---|
54 | Finally, there is the very difficult problem of blocking and unblocking idle threads for workloads with extreme oscillations in CPU needs. |
---|
55 | |
---|
56 | \subsection{Synchronously Multiplexing System Calls} |
---|
57 | |
---|
58 | 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}. |
---|
59 | 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. |
---|
60 | 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. |
---|
61 | |
---|
62 | \subsection{Better Atomic Operations} |
---|
63 | |
---|
64 | When writing low-level concurrent programs, especially lock/wait-free programs, low-level atomic instructions need to be used. |
---|
65 | In C, the gcc-builtin atomics~\cite{gcc:atomics} are commonly used, but leave much to be desired. |
---|
66 | Some of the problems include the following. |
---|
67 | Archaic and opaque macros often have to be used to ensure that atomic assembly is generated instead of locks. |
---|
68 | The builtins are polymorphic, but not type safe since they use void pointers. |
---|
69 | 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. |
---|
70 | Furthermore, these atomics also often require a user to understand how to fence appropriately to ensure correctness. |
---|
71 | All these problems and more could benefit from language support in \CFA. |
---|
72 | 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. |
---|
73 | |
---|