Changeset fc96890 for doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex

Timestamp:

Sep 13, 2022, 3:07:25 PM (22 months ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

3606fe4

Parents:

1c334d1

Message:

Ran second spell/grammar checker and now the cows have come home

File:

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

doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex

@@ -2 +2 @@
 
 Building the \CFA runtime has been a challenging project.
-The work was divided between high-level concurrency design and a user-level threading runtime (Masters's thesis), and low-level support of the user-level runtime using OS kernel-threading and its (multiple) I/O subsystems (Ph.D. thesis).
+The work was divided between high-level concurrency design and a user-level threading runtime (Masters' thesis), and low-level support of the user-level runtime using OS kernel threading and its (multiple) I/O subsystems (Ph.D. thesis).
 Because I am the main developer for both components of this project, there is strong continuity across the design and implementation.
 This continuity provides a consistent approach to advanced control flow and concurrency, with easier development, management and maintenance of the runtime in the future.
 
-I believed my Masters's work would provide the background to make the Ph.D. work reasonably straightforward.
+I believed my Masters' work would provide the background to make the Ph.D. work reasonably straightforward.
 However, I discovered two significant challenges.
 
@@ -20 +20 @@
 Second, the kernel locking, threading, and I/O in the Linux operating system offer very little flexibility and are not designed to facilitate user-level threading.
 There are multiple concurrency aspects in Linux that require carefully following a strict procedure to achieve acceptable performance.
-To be fair, many of these concurrency aspects were designed 30-40 years ago, when there were few multi-processor computers and concurrency knowledge was just developing.
+To be fair, many of these concurrency aspects were designed 30-40 years ago, when there were few multiprocessor computers and concurrency knowledge was just developing.
 Unfortunately, little has changed in the intervening years.
 
@@ -26 +26 @@
 The positive is that @io_uring@ supports the panoply of I/O mechanisms in Linux;
 hence, the \CFA runtime uses one I/O mechanism to provide non-blocking I/O, rather than using @select@ to handle TTY I/O, @epoll@ to handle network I/O, and managing a thread pool to handle disk I/O.
-Merging all these different I/O mechanisms into a coherent scheduling implementation would require much more work than what is present in this thesis, as well as detailed knowledge of multiple I/O mechanisms.
+Merging all these different \io mechanisms into a coherent scheduling implementation would require much more work than what is present in this thesis, as well as detailed knowledge of multiple I/O mechanisms.
 The negative is that @io_uring@ is new and developing.
 As a result, there is limited documentation, few places to find usage examples, and multiple errors that required workarounds.
@@ -75 +75 @@
 
 \section{Future Work}
-While the \CFA runtime achieves a better compromise, than other schedulers, in terms of performance and fairness, I believe further improvements can be made to reduce or eliminate the few cases where performance does deteriorate.
+While the \CFA runtime achieves a better compromise than other schedulers, in terms of performance and fairness, I believe further improvements can be made to reduce or eliminate the few cases where performance does deteriorate.
 Fundamentally, achieving performance and starvation freedom will always be goals with opposing needs even outside of scheduling algorithms.
 
 \subsection{Idle Sleep}
-A difficult challenge, not fully addressed in this thesis, is idle-sleep.
+A difficult challenge, not fully addressed in this thesis, is idle sleep.
 While a correct and somewhat low-cost idle-sleep mechanism is presented, several of the benchmarks show notable performance degradation when too few \ats are present in the system.
 The idle sleep mechanism could therefore benefit from a reduction of spurious cases of sleeping.
@@ -88 +88 @@
 \begin{itemize}
 \item
-The mechanism uses a hand-shake between notification and sleep to ensure that no \at is missed.
+The mechanism uses a handshake between notification and sleep to ensure that no \at is missed.
 \item
-The hand-shake correctness is critical when the last \proc goes to sleep but could be relaxed when several \procs are awake.
+The handshake correctness is critical when the last \proc goes to sleep but could be relaxed when several \procs are awake.
 \item
 Furthermore, organizing the sleeping \procs as a LIFO stack makes sense to keep cold \procs as cold as possible, but it might be more appropriate to attempt to keep cold CPU sockets instead.