Changes in doc/theses/colby_parsons_MMAth/text/conclusion.tex [1f10959:9509d67a]

File:

• doc/theses/colby_parsons_MMAth/text/conclusion.tex (modified) (5 diffs)

doc/theses/colby_parsons_MMAth/text/conclusion.tex

@@ -5 +5 @@
 % ======================================================================
 
-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.
-The presented features achieves this goal, and provides users with the means to write scalable programs in \CFA through multiple avenues.
-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.
-Programmers often have preferences between computing paradigms and concurrency is no exception.
-If users prefer the message passing paradigm of concurrency, \CFA now provides message passing utilities in the form of an actor system and channels.
-For shared memory concurrency, the mutex statement provides a safe and easy-to-use interface for mutual exclusion.
-The @waituntil@ statement aids in writing concurrent programs in both the message passing and shared memory paradigms of concurrency.
-Furthermore, no other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's @waituntil@.
-This work successfully provides users with familiar concurrent language support, but with additional value added over similar utilities in other popular languages.
+The goal of this thesis is to expand concurrent support in \CFA to fill in gaps and increase support for writing safe and efficient concurrent programs.
+The presented features achieve this goal and provide users with the means to write scalable concurrent programs in \CFA through multiple avenues.
+Additionally, the tools presented provide safety and productivity features including: detection of deadlock and other common concurrency errors, easy concurrent shutdown, and toggleable performance statistics.
 
-On overview of the contributions in this thesis include the following:
+For locking, the mutex statement provides a safe and easy-to-use interface for mutual exclusion.
+If programmers prefer the message-passing paradigm, \CFA now supports it in the form of channels and actors.
+The @waituntil@ statement simplifies writing concurrent programs in both the message-passing and shared-memory paradigms of concurrency.
+Finally, no other programming language provides a synchronous multiplexing tool that is polymorphic over resources like \CFA's @waituntil@.
+This work successfully provides users with familiar concurrent-language support, but with additional value added over similar utilities in other popular languages.
+
+On overview of the contributions made in this thesis include the following:
 \begin{enumerate}
-\item The mutex statement, which provides performant and deadlock-free multiple lock acquisition.
-\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.
-\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.
-\item A @waituntil@ statement which tackles the hard problem of allowing a thread to safely synch\-ronously wait for some set of concurrent resources.
+\item The mutex statement, which provides performant and deadlock-free multi-lock acquisition.
+\item Channels with comparable performance to Go, which have safety and productivity features including deadlock detection and an easy-to-use exception-based channel @close@ routine.
+\item An in-memory actor system, which achieves the lowest latency message send of systems tested due to the novel copy-queue data structure.
+\item As well, the actor system has built-in detection of six common actor errors, with excellent performance compared to other systems across all benchmarks presented in this thesis.
+\item A @waituntil@ statement, which tackles the hard problem of allowing a thread wait synchronously for an arbitrary set of concurrent resources.
 \end{enumerate}
 
-The features presented are commonly used in conjunction to solve concurrent problems.
-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.
-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.
-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.
-A user of \CFA does not have to solely subscribe to the message passing or shared memory concurrent paradigm.
-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.
+The added features are now commonly used to solve concurrent problems in \CFA.
+The @mutex@ statement sees use across almost all concurrent code in \CFA, as it is the simplest mechanism for providing thread-safe input and output.
+The channels and the @waituntil@ statement see use in programs where a thread operates as a server or administrator, which accepts and distributes work among channels based on some shared state.
+When implemented, the polymorphic support of the @waituntil@ statement will see use with the actor system to enable user threads outside the actor system to wait for work to be done or for actors to finish.
+Finally, the new features are often combined, \eg channels pass pointers to shared memory that may still need mutual exclusion, requiring the @mutex@ statement to be used.
 
 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.
 Performance results verify that each new feature is comparable or better than similar features in other programming languages.
-All in all, this suite of concurrent tools expands users' ability to easily write safe and performant multi-threaded programs in \CFA.
+All in all, this suite of concurrent tools expands a \CFA programmer's ability to easily write safe and performant multi-threaded programs.
 
 \section{Future Work}
@@ -40 +40 @@
 This thesis only scratches the surface of implicit concurrency by providing an actor system.
 There is room for more implicit concurrency tools in \CFA.
-User-defined implicit concurrency in the form of annotated loops or recursive concurrent functions exists in many other languages and libraries~\cite{uC++,OpenMP}.
+User-defined implicit concurrency in the form of annotated loops or recursive concurrent functions exists in other languages and libraries~\cite{uC++,OpenMP}.
 Similar implicit concurrency mechanisms could be implemented and expanded on in \CFA.
 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.
@@ -46 +46 @@
 \subsection{Advanced Actor Stealing Heuristics}
 
-In this thesis, two basic victim-selection heuristics are chosen when implementing the work stealing actor system.
-Good victim selection is an active area of work stealing research, especially when taking into account NUMA effects and cache locality~\cite{barghi18,wolke17}.
+In this thesis, two basic victim-selection heuristics are chosen when implementing the work-stealing actor-system.
+Good victim selection is an active area of work-stealing research, especially when taking into account NUMA effects and cache locality~\cite{barghi18,wolke17}.
 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.
 Another question in work stealing is: when should a worker thread steal?
-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.
+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.
 Given that thief threads often have cycles to spare, there is room for a more nuanced approaches when stealing.
 Finally, there is the very difficult problem of blocking and unblocking idle threads for workloads with extreme oscillations in CPU needs.
@@ -56 +56 @@
 \subsection{Synchronously Multiplexing System Calls}
 
-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}.
+There are many tools that try to synchronously wait for or asynchronously check I/O.
+Improvements in this area pay dividends in many areas of I/O based programming~\cite{linux:select,linux:poll,linux:epoll,linux:iouring}.
 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.
 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.
@@ -69 +70 @@
 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.
 Furthermore, these atomics also often require a user to understand how to fence appropriately to ensure correctness.
-All these problems and more could benefit from language support in \CFA.
+All these problems and more would benefit from language support in \CFA.
 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.