| 1 | % ====================================================================== |
|---|
| 2 | % ====================================================================== |
|---|
| 3 | \chapter{Conclusion}\label{s:conclusion} |
|---|
| 4 | % ====================================================================== |
|---|
| 5 | % ====================================================================== |
|---|
| 6 | This thesis presented a suite of safe and efficient concurrency tools that provide users with the means to write scalable programs in \CFA through many avenues. |
|---|
| 7 | If users prefer the message passing paradigm of concurrency, \CFA now provides tools in the form of a performant actor system and channels. |
|---|
| 8 | For shared memory concurrency the mutex statement provides a safe and easy-to-use interface for mutual exclusion. |
|---|
| 9 | The waituntil statement provided by this works aids in writing concurrent programs in both the message passing and shared memory worlds of concurrency. |
|---|
| 10 | Furthermore no other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's waituntil. |
|---|
| 11 | From the novel copy queue data structure in the actor system, to the plethora of user-supporting safety features, all these utilities build upon existing tools with value added. |
|---|
| 12 | |
|---|
| 13 | \section{Future Work} |
|---|
| 14 | \subsection{Further Implicit Concurrency} |
|---|
| 15 | This thesis scratches the surface of implicit concurrency by providing an actor system. |
|---|
| 16 | There is room for more implicit concurrency tools in \CFA. |
|---|
| 17 | User-defined implicit concurrency in the form of annotated loops or recursive functions exists in many other languages~\cite{} and could be implemented and expanded on in \CFA. |
|---|
| 18 | Additionally, the problem of automatic parallelism of sequential programs via the compiler is an interesting research space that other languages have approached~\cite{} that could also be explored in \CFA. |
|---|
| 19 | |
|---|
| 20 | |
|---|
| 21 | \subsection{Synchronously Multiplexing System Calls} |
|---|
| 22 | There are many tools that try to sychronize on or asynchronously check I/O, since improvements in this area pay dividends in many areas of computer science~\cite{}. %cite all the poll/iouring utilities |
|---|
| 23 | 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. |
|---|
| 24 | |
|---|
| 25 | \subsection{Better Atomics} |
|---|
| 26 | When writing low level concurrent programs, expecially lock/wait-free programs, low level atomic instructions need to be used. |
|---|
| 27 | In C, the gcc-builtin atomics~\cite{} are commonly used, but leave much to be desired. |
|---|
| 28 | Some of the problems include the following. |
|---|
| 29 | Archaic and opaque macros often have to be used to ensure that atomic assembly is generated instead of locks. |
|---|
| 30 | The builtins are polymorphic, but not type safe since they use void pointers. |
|---|
| 31 | The semantics and safety of these builtins require careful navigation since they require the user to have a nuanced understanding of concurrent memory ordering models to pass via flags. |
|---|
| 32 | Furthermore, these atomics also often require a user to understand how to fence appropriately to ensure correctness. |
|---|
| 33 | All these problems and more could benefit from language support, and adding said language support in \CFA could constitute a great research contribution, and allow for easier writing of low-level safe concurrent code. |
|---|
