| [14e1053] | 1 | % ======================================================================
|
|---|
| 2 | % ======================================================================
|
|---|
| 3 | \chapter{Conclusion}\label{s:conclusion}
|
|---|
| 4 | % ======================================================================
|
|---|
| 5 | % ======================================================================
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [5e81a9c] | 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.
|
|---|
| [c1b6bc6] | 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 |
|
|---|
| [d3c3261] | 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.
|
|---|
| [000d68f] | 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.
|
|---|
| [d3c3261] | 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 synchronously 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.
|
|---|
| [14e1053] | 24 |
|
|---|
| 25 | \section{Future Work}
|
|---|
| [c1b6bc6] | 26 |
|
|---|
| [14e1053] | 27 | \subsection{Further Implicit Concurrency}
|
|---|
| [c1b6bc6] | 28 |
|
|---|
| 29 | This thesis only scratches the surface of implicit concurrency by providing an actor system.
|
|---|
| [14e1053] | 30 | There is room for more implicit concurrency tools in \CFA.
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [14e1053] | 34 |
|
|---|
| [5e81a9c] | 35 | \subsection{Advanced Actor Stealing Heuristics}
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [14e1053] | 44 |
|
|---|
| 45 | \subsection{Synchronously Multiplexing System Calls}
|
|---|
| [c1b6bc6] | 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}.
|
|---|
| [14e1053] | 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.
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [14e1053] | 50 |
|
|---|
| [c9019ce] | 51 | \subsection{Better Atomic Operations}
|
|---|
| [c1b6bc6] | 52 |
|
|---|
| 53 | When writing low-level concurrent programs, especially lock/wait-free programs, low-level atomic instructions need to be used.
|
|---|
| [c9019ce] | 54 | In C, the gcc-builtin atomics~\cite{gcc:atomics} are commonly used, but leave much to be desired.
|
|---|
| [14e1053] | 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.
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [14e1053] | 59 | Furthermore, these atomics also often require a user to understand how to fence appropriately to ensure correctness.
|
|---|
| [5e81a9c] | 60 | All these problems and more could benefit from language support in \CFA.
|
|---|
| [c1b6bc6] | 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.
|
|---|
| [930a800] | 62 |
|
|---|