Changeset 6e83384

Timestamp:

Mar 30, 2023, 8:48:02 PM (20 months ago)

Author:

caparsons <caparson@…>

Branches:

ADT, ast-experimental, master

Children:

3d08cea, eb47a80

Parents:

c7f6786

Message:

did more editing, finished first draft of mutex stmt and channel chapters, added brief intro

Location:

doc/theses/colby_parsons_MMAth

Files:

• Makefile (modified) (1 diff)
• glossary.tex (modified) (2 diffs)
• local.bib (modified) (1 diff)
• text/actors.tex (modified) (1 diff)
• text/channels.tex (modified) (2 diffs)
• text/intro.tex (added)
• text/mutex_stmt.tex (modified) (3 diffs)
• thesis.tex (modified) (1 diff)

doc/theses/colby_parsons_MMAth/Makefile

@@ -46 +46 @@
         figures/nasus_Aggregate_Lock_4  \
         figures/nasus_Aggregate_Lock_8  \
+        figures/nasus_Channel_Contention \
+        figures/pyke_Channel_Contention \
 }
 

doc/theses/colby_parsons_MMAth/glossary.tex

@@ -9 +9 @@
 % \textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
 % }
-
+% C_TODO: replace usages of these acronyms with \acrshort{name}
 \newacronym{tls}{TLS}{Thread Local Storage}
 \newacronym{api}{API}{Application Program Interface}
@@ -16 +16 @@
 \newacronym{rtti}{RTTI}{Run-Time Type Information}
 \newacronym{fcfs}{FCFS}{First Come First Served}
+\newacronym{toctou}{TOCTOU}{time-of-check to time-of-use}

doc/theses/colby_parsons_MMAth/local.bib

@@ -47 +47 @@
   publisher={ACM New York, NY, USA}
 }
+
+@mastersthesis{Beach21,
+author={{Beach, Andrew James}},
+title={Exception Handling in C∀},
+year={2021},
+publisher="UWSpace",
+url={http://hdl.handle.net/10012/17617}
+}

doc/theses/colby_parsons_MMAth/text/actors.tex

@@ -334 +334 @@
 
 \section{Safety and Productivity}
-\CFA's actor system comes with a suite of safety and productivity features. Most of these features are present in \CFA's debug mode, but are removed when code is compiled in nodebug mode. Some of the features include:
+\CFA's actor system comes with a suite of safety and productivity features. Most of these features are present in \CFA's debug mode, but are removed when code is compiled in nodebug mode. The suit of features include the following.
 
 \begin{itemize}

doc/theses/colby_parsons_MMAth/text/channels.tex

@@ -5 +5 @@
 % ======================================================================
 
-Channels were first introduced by Hoare in his paper Communicating Sequentual Processes~\cite{Hoare78}, where he proposes a concurrent language that communicates across processes using input/output channels to send data inbetween processes. Channels are used to perform message passing concurrency, a model of concurrency where threads communicate by sending data to each other, and synchronizing via the passing mechanism. This is an alternative to shared memory concurrency, where threads can communicate directly by changing shared memory state. Most modern concurrent programming languages do not subscribe to just one style of communication between threads, and provide features that support both. Channels as a programming language feature has been popularized in recent years due to the language Go, which encourages the use of channels as its fundamental concurrent feature.
+Channels were first introduced by Hoare in his paper Communicating Sequentual Processes~\cite{Hoare78}, where he proposes a concurrent language that communicates across processes using input/output channels to send data. Channels are a concurrent language feature used to perform message passing concurrency, a model of concurrency where threads communicate by sending data as messages, and synchronizing via the message passing mechanism. This is an alternative to shared memory concurrency, where threads can communicate directly by changing shared memory state. Most modern concurrent programming languages do not subscribe to just one style of communication between threads, and provide features that support both. Channels as a programming language feature has been popularized in recent years due to the language Go, which encourages the use of channels as its fundamental concurrent feature.
 
 \section{Producer-Consumer Problem}
@@ -14 +14 @@
 
 \section{Channel Implementation}
-% C_TODO: rewrite to reflect on current impl
+The channel implementation in \CFA is a near carbon copy of the Go implementation. Experimentation was conducted that varied the producer-consumer problem algorithm and lock type used inside the channel. With the exception of non-FCFS algorithms, no algorithm or lock usage in the channel implementation was found to be consistently more performant that Go's choice of algorithm and lock implementation. As such the research contributions added by \CFA's channel implementation lie in the realm of safety and productivity features.
+
+\section{Safety and Productivity}
+Channels in \CFA come with safety and productivity features to aid users. The features include the following.
+
+\begin{itemize}
+\item Toggle-able statistic collection on channel behvaiour that counts channel operations, and the number of the operations that block. Tracking blocking operations helps users tune their channel size or channel usage when the channel is used for buffering, where the aim is to have as few blocking operations as possible.
+\item Deadlock detection on deallocation of the channel. If any threads are blocked inside the channel when it terminates it is detected and informs the user, as this would cause a deadlock.
+\item A \code{flush} routine that delivers copies of an element to all waiting consumers, flushing the buffer. Programmers can use this to easily to broadcast data to multiple consumers. Additionally, the \code{flush} routine is more performant then looping around the \code{insert} operation since it can deliver the elements without having to reaquire mutual exclusion for each element sent.
+\end{itemize}
+
+The other safety and productivity feature of \CFA channels deals with concurrent termination. Terminating concurrent programs is often one of the most difficult parts of writing concurrent code, particularly if graceful termination is needed. The difficulty of graceful termination often arises from the usage of synchronization primitives which need to be handled carefully during shutdown. It is easy to deadlock during termination if threads are left behind on synchronization primitives. Additionally, most synchronization primitives are prone to time-of-check to time-of-use (TOCTOU) issues where there is race between one thread checking the state of a concurrent object and another thread changing the state. TOCTOU issues with synchronization primitives often involve a race between one thread checking the primitive for blocked threads and another thread blocking on it. Channels are a particularly hard synchronization primitive to terminate since both sending and receiving off a channel can block. Thus, improperly handled TOCTOU issues with channels often result in deadlocks as threads trying to perform the termination may end up unexpectedly blocking in their attempt to help other threads exit the system.
+
+% C_TODO: add reference to select chapter, add citation to go channels info
+Go channels provide a set of tools to help with concurrent shutdown. Channels in Go have a \code{close} operation and a \code{select} statement that both can be used to help threads terminate. The \code{select} statement will be discussed in \ref{}, where \CFA's \code{waituntil} statement will be compared with the Go \code{select} statement. The \code{close} operation on a channel in Go changes the state of the channel. When a channel is closed, sends to the channel will panic and additional calls to \code{close} will panic. Receives are handled differently where receivers will never block on a closed channel and will continue to remove elements from the channel. Once a channel is empty, receivers can continue to remove elements, but will receive the zero-value version of the element type. To aid in avoiding unwanted zero-value elements, Go provides the ability to iterate over a closed channel to remove the remaining elements. These design choices for Go channels enforce a specific interaction style with channels during termination, where careful thought is needed to ensure that additional \code{close} calls don't occur and that no sends occur after channels are closed. These design choices fit Go's paradigm of error management, where users are expected to explicitly check for errors, rather than letting errors occur and catching them. If errors need to occur in Go, return codes are used to pass error information where they are needed. Note that panics in Go can be caught, but it is not considered an idiomatic way to write Go programs.
+
+While Go's channel closing semantics are powerful enough to perform any concurrent termination needed by a program, their lack of ease of use leaves much to be desired. Since both closing and sending panic, once a channel is closed, a user often has to synchronize the senders to a channel before the channel can be closed to avoid panics. However, in doing so it renders the \code{close} operation nearly useless, as the only utilities it provides are the ability to ensure that receivers no longer block on the channel, and will receive zero-valued elements. This can be useful if the zero-typed element is recognized as a sentinel value, but if another sentinel value is preferred, then \code{close} only provides its non-blocking feature. To avoid TOCTOU issues during shutdown, a busy wait with a \code{select} statement is often used to add or remove elements from a channel. Due to Go's asymmetric approach to channel shutdown, separate synchronization between producers and consumers of a channel has to occur during shutdown.
+
+In \CFA, exception handling is an encouraged paradigm and has full language support \cite{}.
+% \cite{Beach21}. TODO: this citation breaks when compiled. Need to fix and insert above
+As such \CFA uses an exception based approach to channel shutdown that is symmetric for both producers and consumers, and supports graceful shutdown.Exceptions in \CFA support both termination and resumption.Termination exceptions operate in the same way as exceptions seen in many popular programming languages such as \CC, Python and Java.
+Resumption exceptions are a style of exception that when caught run the corresponding catch block in the same way that termination exceptions do.
+The difference between the exception handling mechanisms arises after the exception is handled. In termination handling, the control flow continues into the code following the catch after the exception is handled. In resumption handling, the control flow returns to the site of the \code{throw}, allowing the control to continue where it left off. Note that in resumption, since control can return to the point of error propagation, the stack is not unwound during resumption propagation. In \CFA if a resumption is not handled, it is reraised as a termination. This mechanism can be used to create a flexible and robust termination system for channels.
+
+When a channel in \CFA is closed, all subsequent calls to the channel will throw a resumption exception at the caller. If the resumption is handled, then the caller will proceed to attempt to complete their operation. If the resumption is not handled it is then rethrown as a termination exception. Or, if the resumption is handled, but the subsequent attempt at an operation would block, a termination exception is thrown. These termination exceptions allow for non-local transfer that can be used to great effect to eagerly and gracefully shut down a thread. When a channel is closed, if there are any blocked producers or consumers inside the channel, they are woken up and also have a resumption thrown at them. The resumption exception, \code{channel_closed}, has a couple fields to aid in handling the exception. The exception contains a pointer to the channel it was thrown from, and a pointer to an element. In exceptions thrown from remove the element pointer will be null. In the case of insert the element pointer points to the element that the thread attempted to insert. This element pointer allows the handler to know which operation failed and also allows the element to not be lost on a failed insert since it can be moved elsewhere in the handler. Furthermore, due to \CFA's powerful exception system, this data can be used to choose handlers based which channel and operation failed. Exception handlers in \CFA have an optional predicate after the exception type which can be used to optionally trigger or skip handlers based on the content of an exception. It is worth mentioning that the approach of exceptions for termination may incur a larger performance cost during termination that the approach used in Go. This should not be an issue, since termination is rarely an fast-path of an application and ensuring that termination can be implemented correctly with ease is the aim of the exception approach.
+
+To highlight the differences between \CFA's and Go's close semantics, an example program is presented. The program is a barrier implemented using two channels shown in Listings~\ref{l:cfa_chan_bar} and \ref{l:go_chan_bar}. Both of these exaples are implmented using \CFA syntax so that they can be easily compared. Listing~\ref{l:go_chan_bar} uses go-style channel close semantics and Listing~\ref{l:cfa_chan_bar} uses \CFA close semantics. In this problem it is infeasible to use the Go \code{close} call since all tasks are both potentially producers and consumers, causing panics on close to be unavoidable. As such in Listing~\ref{l:go_chan_bar} to implement a flush routine for the buffer, a sentinel value of $-1$ has to be used to indicate to threads that they need to leave the barrier. This sentinel value has to be checked at two points. Furthermore, an additional flag \code{done} is needed to communicate to threads once they have left the barrier that they are done. This use of an additional flag or communication method is common in Go channel shutdown code, since to avoid panics on a channel, the shutdown of a channel often has to be communicated with threads before it occurs. In the \CFA version~\ref{l:cfa_chan_bar}, the barrier shutdown results in an exception being thrown at threads operating on it, which informs the threads that they must terminate. This avoids the need to use a separate communication method other than the barrier, and avoids extra conditional checks on the fast path of the barrier implementation. Also note that in the Go version~\ref{l:go_chan_bar}, the size of the barrier channels has to be larger than in the \CFA version to ensure that the main thread does not block when attempting to clear the barrier.
+
+\begin{cfacode}[tabsize=3,caption={\CFA channel barrier termination},label={l:cfa_chan_bar}]
+struct barrier {
+    channel( int ) barWait;
+    channel( int ) entryWait;
+    int size;
+}
+void ?{}(barrier & this, int size) with(this) {
+    barWait{size};
+    entryWait{size};
+    this.size = size;
+    for ( j; size )
+        insert( *entryWait, j );
+}
+
+void flush(barrier & this) with(this) {
+    close(barWait);
+    close(entryWait);
+}
+void wait(barrier & this) with(this) {
+    int ticket = remove( *entryWait );
+    if ( ticket == size - 1 ) {
+        for ( j; size - 1 )
+            insert( *barWait, j );
+        return;
+    }
+    ticket = remove( *barWait );
+
+    // last one out
+    if ( size == 1 || ticket == size - 2 ) {
+        for ( j; size )
+            insert( *entryWait, j );
+    }
+}
+barrier b{Tasks};
+
+// thread main
+void main(Task & this) {
+    try {
+        for ( ;; ) {
+            wait( b );
+        }
+    } catch ( channel_closed * e ) {}
+}
+
+int main() {
+    {
+        Task t[Tasks];
+
+        sleep(10`s);
+        flush( b );
+    } // wait for tasks to terminate
+    return 0;
+}
+\end{cfacode}
+
+\begin{cfacode}[tabsize=3,caption={Go channel barrier termination},label={l:go_chan_bar}]
+
+struct barrier {
+    channel( int ) barWait;
+    channel( int ) entryWait;
+    int size;
+}
+void ?{}(barrier & this, int size) with(this) {
+    barWait{size + 1};
+    entryWait{size + 1};
+    this.size = size;
+    for ( j; size )
+        insert( *entryWait, j );
+}
+
+void flush(barrier & this) with(this) {
+    insert( *entryWait, -1 );
+    insert( *barWait, -1 );
+}
+void wait(barrier & this) with(this) {
+    int ticket = remove( *entryWait );
+    if ( ticket == -1 ) {
+        insert( *entryWait, -1 );
+        return;
+    }
+    if ( ticket == size - 1 ) {
+        for ( j; size - 1 )
+            insert( *barWait, j );
+        return;
+    }
+    ticket = remove( *barWait );
+    if ( ticket == -1 ) {
+        insert( *barWait, -1 );
+        return;
+    }
+
+    // last one out
+    if ( size == 1 || ticket == size - 2 ) {
+        for ( j; size )
+            insert( *entryWait, j );
+    }
+}
+barrier b;
+
+bool done = false;
+// thread main
+void main(Task & this) {
+    for ( ;; ) {
+        if ( done ) break;
+        wait( b );
+    }
+}
+
+int main() {
+    {
+        Task t[Tasks];
+
+        sleep(10`s);
+        done = true;
+
+        flush( b );
+    } // wait for tasks to terminate
+    return 0;
+}
+\end{cfacode}
+
+In Listing~\ref{l:cfa_resume} an example of channel closing with resumption is used. This program uses resumption in the \code{Consumer} thread main to ensure that all elements in the channel are removed before the consumer thread terminates. The producer only has a \code{catch} so the moment it receives an exception it terminates, whereas the consumer will continue to remove from the closed channel via handling resumptions until the buffer is empty, which then throws a termination exception. If the same program was implemented in Go it would require explicit synchronization with both producers and consumers by some mechanism outside the channel to ensure that all elements were removed before task termination.
+
+\begin{cfacode}[tabsize=3,caption={\CFA channel resumption usage},label={l:cfa_resume}]
+channel( int ) chan{ 128 };
+
+// Consumer thread main
+void main(Consumer & this) {
+    size_t runs = 0;
+    try {
+        for ( ;; ) {
+            remove( chan );
+        }
+    } catchResume ( channel_closed * e ) {}
+    catch ( channel_closed * e ) {} 
+}
+
+// Producer thread main
+void main(Producer & this) {
+    int j = 0;
+    try {
+        for ( ;;j++ ) {
+            insert( chan, j );
+        }
+    } catch ( channel_closed * e ) {} 
+}
+
+int main( int argc, char * argv[] ) {
+    {
+        Consumers c[4];
+        Producer p[4];
+
+        sleep(10`s);
+
+        for ( i; Channels )
+            close( channels[i] );
+    }
+    return 0;
+}
+\end{cfacode}
+
+\section{Performance}
+
+Given that the base implementation of the \CFA channels is very similar to the Go implementation, this section aims to show that the performance of the two implementations are comparable. One microbenchmark is conducted to compare Go and \CFA. The benchmark is a ten second experiment where producers and consumers operate on a channel in parallel and throughput is measured. The number of cores is varied to measure how throughtput scales. The cores are divided equally between producers and consumers, with one producer or consumer owning each core. The results of the benchmark are shown in Figure~\ref{f:chanPerf}. The performance of Go and \CFA channels on this microbenchmark is comparable. Note, it is expected for the performance to decline as the number of cores increases as the channel operations all occur in a critical section so an increase in cores results in higher contention with no increase in parallelism.
+
 
 \begin{figure}
-\begin{lrbox}{\myboxA}
-\begin{cfacode}[aboveskip=0pt,belowskip=0pt,basicstyle=\footnotesize]
-int size;
-int front, back, count;
-TYPE * buffer;
-cond_var prods, cons;
-lock mx;
-
-void insert( TYPE elem ){
-
-    lock(mx);
-
-    // wait if buffer is full
-    // insert finished by consumer
-    if (count == size){ 
-        wait(prods, mx, &elem);
-        // no reacquire
-        return;
-    }
-
-
-
-
-    if (!empty(cons)){
-        // do consumer work
-        front(cons) = &elem;
-        notify_one(cons);
-    }
-
-
-    
-    else
-        insert_(chan, elem);
-
-
-    unlock(mx);
-}
-\end{cfacode}
-\end{lrbox}
-\begin{lrbox}{\myboxB}
-\begin{cfacode}[aboveskip=0pt,belowskip=0pt,basicstyle=\footnotesize]
-int size;
-int front, back, count;
-TYPE * buffer;
-thread * chair;
-TYPE * chair_elem;
-lock c_lock, p_lock, mx;
-void insert( TYPE elem ){
-    lock(p_lock);
-    lock(mx);
-
-    // wait if buffer is full
-    // insert finished by consumer
-    if (count == size){
-        chair = this_thread();
-        chair_elem = &elem;
-        unlock(mx);
-        park();
-        unlock(p_lock);
-        return;
-    }
-
-    if (chair != 0p){
-        // do consumer work
-        chair_elem = &elem;
-        unpark(chair);
-        chair = 0p;
-        unlock(mx);
-        unlock(p_lock);
-        return;
-    } else 
-        insert_(chan, elem);
-
-    unlock(mx);
-    unlock(p_lock);
-}
-\end{cfacode}
-\end{lrbox}
-\subfloat[Go implementation]{\label{f:GoChanImpl}\usebox\myboxA}
-\hspace{5pt}
-\vrule
-\hspace{5pt}
-\subfloat[\CFA implementation]{\label{f:cfaChanImpl}\usebox\myboxB}
-\caption{Comparison of channel implementations}
-\label{f:ChanComp}
+    \centering
+    \begin{subfigure}{0.5\textwidth}
+        \centering
+        \scalebox{0.5}{\input{figures/nasus_Channel_Contention.pgf}}
+        \subcaption{AMD \CFA Channel Benchmark}\label{f:chanAMD}
+    \end{subfigure}\hfill
+    \begin{subfigure}{0.5\textwidth}
+        \centering
+        \scalebox{0.5}{\input{figures/pyke_Channel_Contention.pgf}}
+        \subcaption{Intel \CFA Channel Benchmark}\label{f:chanIntel}
+    \end{subfigure}
+    \caption{The channel contention benchmark comparing \CFA and Go channel throughput (higher is better).}
+    \label{f:chanPerf}
 \end{figure}
-
-Go and \CFA have similar channel implementation when it comes to how they solve the producer-consumer problem. Both implementations attempt to minimize double blocking by requiring cooperation from signalling threads. If a consumer or producer is blocked, whichever thread signals it to proceed completes the blocked thread's operation for them so that the blocked thread does not need to acquire any locks. Channels in \CFA go a step further in preventing double blocking. In Figure~\ref{f:ChanComp}, the producer-consumer solutions used by Go and \CFA are presented. Some liberties are taken to simplify the code, such as removing special casing for zero-size buffers, and abstracting the non-concurrent insert into a helper, \code{insert_}. Only the insert routine is presented, as the remove routine is symmetric.
-In the Go implementation \ref{f:GoChanImpl}, first mutual exclusion is acquired. Then if the buffer is full the producer waits on a condition variable and releases the mx lock. Note it will not reacquire the lock upon waking. The 3rd argument to \code{wait} is a pointer that is stored per thread on the condition variable. This pointer can be accessed when the waiting thread is at the from of the condition variable's queue by calling \code{front}. This allows arbitrary data to be stored with waiting tasks in the queue, eliminating the need for a second queue just for data. This producer that waits stores a pointer to the element it wanted to insert, so that the consumer that signals them can insert the element for the producer before signalling. If the buffer is not full a producer will proceed to check if any consumers are waiting. If so then the producer puts its value directly into the consumers hands, bypassing the usage of the buffer. If there are no waiting consumers, the producer inserts the value into the buffer and leaves.
-The \CFA implementation \ref{f:cfaChanImpl} it follows a similar pattern to the Go implementation, but instead uses three locks and no condition variables. The main idea is that the \CFA implementation forgoes the use of a condition variable by making all producers wait on the outer lock \code{p_lock} once a single producer has to wait inside the critical section. This also happens with consumers. This further reduces double blocking by ensuring that the only threads that can enter the critical section after a producer is blocked are consumers and vice versa. Additionally, entering consumers to not have to contend for the \code{mx} lock once producers are waiting and vice versa. Since only at most one thread will be waiting in the critical section, condition variables are not needed and a barebones thread \code{park} and \code{unpark} will suffice. The operation \code{park} blocks a thread and \code{unpark} is passed a pointer to a thread to wake up. This algorithm can be written using a single condition variable instead of park/unpark, but using park/unpark eliminates the need for any queueing operations. Now with the understanding of park/unpark it is clear to see the similarity between the two algorithms. The main difference being the \code{p_lock} acquisitions and releases. Note that \code{p_lock} is held until after waking from \code{park}, which provides the guarantee than no other producers will enter until the first producer to enter makes progress.
-
-\section{Safety and Productivity}
-
-
-\section{Performance}

doc/theses/colby_parsons_MMAth/text/mutex_stmt.tex

@@ -18 +18 @@
 
 \section{Other Languages}
-There are similar concepts to the mutex statement that exist in other languages. Java has a feature called a synchronized statement, which looks identical to \CFA's mutex statement, but it has some differences. The synchronized statement only accepts one item in its clause. Any object can be passed to the synchronized statement in Java since all objects in Java are monitors, and the synchronized statement acquires that object's monitor. In \CC there is a feature in the \code{<mutex>} header called scoped\_lock, which is also similar to the mutex statement. The scoped\_lock is a class that takes in any number of locks in its constructor, and acquires them in a deadlock-free manner. It then releases them when the scoped\_lock object is deallocated, thus using RAII. An example of \CC scoped\_lock usage is shown in Listing~\ref{l:cc_scoped_lock}.
+There are similar concepts to the mutex statement that exist in other languages. Java has a feature called a synchronized statement, which looks identical to \CFA's mutex statement, but it has some differences. The synchronized statement only accepts a single object in its clause. Any object can be passed to the synchronized statement in Java since all objects in Java are monitors, and the synchronized statement acquires that object's monitor. In \CC there is a feature in the standard library \code{<mutex>} header called scoped\_lock, which is also similar to the mutex statement. The scoped\_lock is a class that takes in any number of locks in its constructor, and acquires them in a deadlock-free manner. It then releases them when the scoped\_lock object is deallocated, thus using RAII. An example of \CC scoped\_lock usage is shown in Listing~\ref{l:cc_scoped_lock}.
 
 \begin{cppcode}[tabsize=3,caption={\CC scoped\_lock usage},label={l:cc_scoped_lock}]
@@ -29 +29 @@
 
 \section{\CFA implementation}
-The \CFA mutex statement can be seen as a combination of the similar featurs in Java and \CC. It can acquire more that one lock in a deadlock-free manner, and releases them via RAII like \CC, however the syntax is identical to the Java synchronized statement. This syntactic choice was made so that the body of the mutex statement is its own scope. Compared to the scoped\_lock, which relies on its enclosing scope, the mutex statement's introduced scope can provide visual clarity as to what code is being protected by the mutex statement, and where the mutual exclusion ends. \CFA's mutex statement and \CC's scoped\_lock both use parametric polymorphism to allow user defined types to work with the feature. \CFA's implementation requires types to support the routines \code{lock()} and \code{unlock()}, whereas \CC requires those routines, plus \code{try_lock()}. The scoped\_lock requires an additional routine since it differs from the mutex statement in how it implements deadlock avoidance.
+The \CFA mutex statement takes some ideas from both the Java and \CC features. The mutex statement can acquire more that one lock in a deadlock-free manner, and releases them via RAII like \CC, however the syntax is identical to the Java synchronized statement. This syntactic choice was made so that the body of the mutex statement is its own scope. Compared to the scoped\_lock, which relies on its enclosing scope, the mutex statement's introduced scope can provide visual clarity as to what code is being protected by the mutex statement, and where the mutual exclusion ends. \CFA's mutex statement and \CC's scoped\_lock both use parametric polymorphism to allow user defined types to work with the feature. \CFA's implementation requires types to support the routines \code{lock()} and \code{unlock()}, whereas \CC requires those routines, plus \code{try_lock()}. The scoped\_lock requires an additional routine since it differs from the mutex statement in how it implements deadlock avoidance.
 
-The parametric polymorphism allows for locking to be defined for types that may want convenient mutual exclusion. An example is \CFA's \code{sout}. \code{sout} is \CFA's output stream, similar to \CC's \code{cout}. \code{sout} has routines that match the mutex statement trait, so the mutex statement can be used to lock the output stream while producing output. In this case, the mutex statement allows the programmer to acquire mutual exclusion over an object without having to know the internals of the object or what locks it needs to acquire. The ability to do so provides both improves safety and programmer productivity since it abstracts away the concurrent details and provides an interface for optional thread-safety. This is a commonly used feature when producing output from a concurrent context, since producing output is not thread safe by default. This use case is shown in Listing~\ref{l:sout}.
+The parametric polymorphism allows for locking to be defined for types that may want convenient mutual exclusion. An example of one such use case in \CFA is \code{sout}. The output stream in \CFA is called \code{sout}, and functions similarly to \CC's \code{cout}. \code{sout} has routines that satisfy the mutex statement trait, so the mutex statement can be used to lock the output stream while producing output. In this case, the mutex statement allows the programmer to acquire mutual exclusion over an object without having to know the internals of the object or what locks need to be acquired. The ability to do so provides both improves safety and programmer productivity since it abstracts away the concurrent details and provides an interface for optional thread-safety. This is a commonly used feature when producing output from a concurrent context, since producing output is not thread safe by default. This use case is shown in Listing~\ref{l:sout}.
 
 \begin{cfacode}[tabsize=3,caption={\CFA sout with mutex statement},label={l:sout}]
-    mutex( sout )
-        sout | "This output is protected by mutual exclusion!"; 
+mutex( sout )
+    sout | "This output is protected by mutual exclusion!"; 
 \end{cfacode}
 
 \section{Deadlock Avoidance}
-The mutex statement uses the deadlock prevention technique of lock ordering, where the circular-wait condition of a deadlock cannot occur if all locks are acquired in the same order. The scoped\_lock uses a deadlock avoidance algorithm where all locks after the first are acquired using \code{try_lock} and if any of the attempts to lock fails, all locks so far are released. This repeats until all locks are acquired successfully. The deadlock avoidance algorithm used by scoped\_lock is shown in Listing~\ref{l:cc_deadlock_avoid}. The algorithm presented is taken straight from the \code{<mutex>} header source, with some renaming and comments for clarity.
+The mutex statement uses the deadlock prevention technique of lock ordering, where the circular-wait condition of a deadlock cannot occur if all locks are acquired in the same order. The scoped\_lock uses a deadlock avoidance algorithm where all locks after the first are acquired using \code{try_lock} and if any of the attempts to lock fails, all locks so far are released. This repeats until all locks are acquired successfully. The deadlock avoidance algorithm used by scoped\_lock is shown in Listing~\ref{l:cc_deadlock_avoid}. The algorithm presented is taken directly from the source code of the \code{<mutex>} header, with some renaming and comments for clarity.
 
 \begin{cppcode}[tabsize=3,caption={\CC scoped\_lock deadlock avoidance algorithm},label={l:cc_deadlock_avoid}]
@@ -59 +59 @@
 \end{cppcode}
 
-The algorithm in \ref{l:cc_deadlock_avoid} successfully avoids deadlock, however there is a potential livelock scenario. Given two threads $A$ and $B$, who create a scoped\_lock with two locks $L1$ and $L2$, a livelock can form as follows. Thread $A$ creates a scoped\_lock with $L1, L2$ in that order, $B$ creates a scoped lock with the order $L2, L1$. Both threads acquire the first lock in their order and then fail the try\_lock since the other lock is held. They then reset their start lock to be their 2nd lock and try again. This time $A$ has order $L2, L1$, and $B$ has order $L1, L2$. This is identical to the starting setup, but with the ordering swapped among threads. As such if they each acquire their first lock before the other acquires their second, they can livelock indefinitely.
+The algorithm in \ref{l:cc_deadlock_avoid} successfully avoids deadlock, however there is a potential livelock scenario. Given two threads $A$ and $B$, who create a scoped\_lock with two locks $L1$ and $L2$, a livelock can form as follows. Thread $A$ creates a scoped\_lock with $L1$, $L2$, and $B$ creates a scoped lock with the order $L2$, $L1$. Both threads acquire the first lock in their order and then fail the try\_lock since the other lock is held. They then reset their start lock to be their 2nd lock and try again. This time $A$ has order $L2$, $L1$, and $B$ has order $L1$, $L2$. This is identical to the starting setup, but with the ordering swapped among threads. As such, if they each acquire their first lock before the other acquires their second, they can livelock indefinitely.
+
 The lock ordering algorithm used in the mutex statement in \CFA is both deadlock and livelock free. It sorts the locks based on memory address and then acquires them. For locks fewer than 7, it sorts using hard coded sorting methods that perform the minimum number of swaps for a given number of locks. For 7 or more locks insertion sort is used. These sorting algorithms were chosen since it is rare to have to hold more than  a handful of locks at a time. It is worth mentioning that the downside to the sorting approach is that it is not fully compatible with usages of the same locks outside the mutex statement. If more than one lock is held by a mutex statement, if more than one lock is to be held elsewhere, it must be acquired via the mutex statement, or else the required ordering will not occur. Comparitively, if the scoped\_lock is used and the same locks are acquired elsewhere, there is no concern of the scoped\_lock deadlocking, due to its avoidance scheme, but it may livelock.
 

doc/theses/colby_parsons_MMAth/thesis.tex

@@ -113 +113 @@
 %----------------------------------------------------------------------
 
-% \input{intro}
+\input{intro}
 
-% \input{CFA_intro}
+\input{CFA_intro}
 
-% \input{CFA_concurrency}
+\input{CFA_concurrency}
 
-% \input{mutex_stmt}
+\input{mutex_stmt}
 
 \input{channels}
 
-% \input{actors}
+\input{actors}
 
 \clearpage