Index: doc/theses/colby_parsons_MMAth/text/channels.tex =================================================================== --- doc/theses/colby_parsons_MMAth/text/channels.tex (revision e59a9faa5ade19bf6de002cee277c49847723078) +++ doc/theses/colby_parsons_MMAth/text/channels.tex (revision 992157317fa74acf52d8f0c4f23e662c8c81fb40) @@ -5,9 +5,16 @@ % ====================================================================== -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 are a concurrent-language feature used to perform \Newterm{message-passing concurrency}: a model of concurrency where threads communicate by sending (mostly nonblocking) data as messages and synchronizing by receiving (blocking) sent data. +This model is an alternative to shared-memory concurrency, where threads can communicate directly by changing shared state. +Most modern concurrent programming languages do not subscribe to just one style of communication among threads and provide features that support multiple approaches. + +Channels were first introduced by Kahn~\cite{Kahn74} and extended by Hoare~\cite{Hoare78} (CSP). +Both papers present a pseudo (unimplemented) concurrent language where processes communicate using input/output channels to send data. +Both languages are highly restrictive. +Kahn's language restricts a reading process to only wait for data on a single channel at a time and different writing processes cannot send data on the same channel. +Hoare's language restricts ... 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. +Go's restrictions are ... +\CFA channels do not have these restrictions. \section{Producer-Consumer Problem} @@ -40,5 +47,5 @@ \begin{itemize} -\item Toggle-able statistic collection on channel behvaiour that counts channel operations, and the number of the operations that block. +\item Toggle-able statistic collection on channel behaviour 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. @@ -46,5 +53,5 @@ \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. +Additionally, the \code{flush} routine is more performant then looping around the \code{insert} operation since it can deliver the elements without having to reacquire mutual exclusion for each element sent. \end{itemize} @@ -107,5 +114,5 @@ 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. +Both of these examples are implemented 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. @@ -118,5 +125,5 @@ 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{cfa}[tabsize=3,caption={\CFA channel barrier termination},label={l:cfa_chan_bar}] +\begin{cfa}[caption={\CFA channel barrier termination},label={l:cfa_chan_bar}] struct barrier { channel( int ) barWait; @@ -173,5 +180,5 @@ \end{cfa} -\begin{cfa}[tabsize=3,caption={Go channel barrier termination},label={l:go_chan_bar}] +\begin{cfa}[caption={Go channel barrier termination},label={l:go_chan_bar}] struct barrier { @@ -244,5 +251,5 @@ 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{cfa}[tabsize=3,caption={\CFA channel resumption usage},label={l:cfa_resume}] +\begin{cfa}[caption={\CFA channel resumption usage},label={l:cfa_resume}] channel( int ) chan{ 128 }; @@ -287,5 +294,5 @@ 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 number of cores is varied to measure how throughput 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}.