Diff [4c2e561f46e37c956d59cd5054091612c978e9cd:3397eedebff24a28a10384d4f162bf850c321072] for / – Cforall

doc/theses/colby_parsons_MMAth/Makefile

r4c2e561	r3397eed
23	23	text/channels \
24	24	text/waituntil \
25		~~text/conclusion \~~
26	25	}
27	26

doc/theses/colby_parsons_MMAth/local.bib

-              r4c2e561
+              r3397eed
+}
+@misc{openmp,
+  author = "OpenMP",
+  title = "OPENMP API Specification",
+  howpublished = {\href{https://www.openmp.org/spec-html/5.0/openmpch1.html}},
+  note = "[Online; accessed 23-May-2023]"
+}
 @techreport{wilson94,
   title={The suif compiler system: a parallelizing and optimizing research compiler},

doc/theses/colby_parsons_MMAth/text/channels.tex

r4c2e561	r3397eed
80	80	This approach is similar to wait morphing for locks~\cite[p.~82]{Butenhof97} and improves performance in a few ways.
81	81	First, each thread interacting with the channel only acquires and releases the internal channel lock once.
82		As a result, contention on the internal lock is decreased~~; only entering threads compete for the lock since~~ unblocking threads do not reacquire the lock.
	82	As a result, contention on the internal lock is decreased, as only entering threads compete for the lock as unblocking threads do not reacquire the lock.
83	83	The other advantage of Go's wait-morphing approach is that it eliminates the bottleneck of waiting for signalled threads to run.
84	84	Note, the property of acquiring/releasing the lock only once can also be achieved with a different form of cooperation, called \Newterm{baton passing}.

doc/theses/colby_parsons_MMAth/text/conclusion.tex

-              r4c2e561
+              r3397eed
 % ======================================================================
 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.
 If users prefer the message passing paradigm of concurrency, \CFA now provides message passing tools in the form of a performant actor system and channels.
+If users prefer the message passing paradigm of concurrency, \CFA now provides tools in the form of a performant 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 provided by this works 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.
+The waituntil statement provided by this works aids in writing concurrent programs in both the message passing and shared memory worlds of concurrency.
+Furthermore no other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's waituntil.
 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.
 …
 This thesis 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 functions exists in many other languages and libraries~\cite{uC++,OpenMP}. Similar implicit concurrency mechanisms could be implemented and expanded on in \CFA.
+User-defined implicit concurrency in the form of annotated loops or recursive functions exists in many other languages and libraries~\cite{uC++,openmp} and 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} that could also be explored in \CFA.
+\subsection{Synchronously Multiplexing System Calls}
+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{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.
 \subsection{Advanced Actor Stealing Heuristics}
 In this thesis, two basic victim selection heuristics were 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 constitute future work. The other question that arises with 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 higher than what is saved by sharing the work. In the presented actor system, a worker thread steals work after it checks all its work queues for work twice and sees them all empty. Given that thief threads often have cycles to spare, there is room for a more nuanced approach to choosing when to steal.
-\subsection{Synchronously Multiplexing System Calls}
-There are many tools that try to sychronously 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}.
-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.
 \subsection{Better Atomic Operations}
 …
 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.
 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.
+Adding good language support for atomics is a difficult and nuanced problem, which if solved well would allow for easier and safer writing of low-level concurrent code.
+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.

doc/theses/colby_parsons_MMAth/text/intro.tex

r4c2e561	r3397eed
13	13	The groundwork for concurrent features in \CFA was implemented by Thierry Delisle~\cite{Delisle18}, who contributed the threading system, coroutines, monitors and other tools.
14	14	This thesis builds on top of that foundation by providing a suite of high-level concurrent features.
15		The features include a @mutex@ statement, channels, a @waituntil@ statement, and an actor system.
	15	The features include a @mutex@ statement, channels and a @waituntil@ statement, and an actor system.
16	16	All of these features exist in other programming in some shape or form, however this thesis extends the original ideas by improving performance, productivity, and safety.

doc/theses/colby_parsons_MMAth/text/waituntil.tex

-              r4c2e561
+              r3397eed
 % ======================================================================
 Consider the following motivating problem.
+Consider the following motivational problem that we shall title the bathroom problem.
 There are @N@ stalls (resources) in a bathroom and there are @M@ people (threads).
+Each stall has its own lock since only one person may occupy a stall at a time.
+Humans tend to solve this problem in the following way.
+They check if all of the stalls are occupied.
+If not they enter and claim an available stall.
+If they are all occupied, the people queue and watch the stalls until one is free and then enter and lock the stall.
+This solution can be implemented on a computer easily if all threads are waiting on all stalls and agree to queue.
+Now the problem is extended.
+Some stalls are wheelchair accessible, some stalls are dirty and other stalls are clean.
+Each person (thread) may choose some subset of dirty, clean and accessible stalls that they want to wait for.
+Immediately the problem becomes much more difficult.
+A single queue no longer fully solves the problem: What happens when there is a stall available that the person at the front of the queue will not choose?
+The naive solution to this problem has each thread to spin indefinitely continually checking the stalls until an suitable one is free.
+This is not good enough since this approach wastes cycles and results in no fairness among threads waiting for stalls as a thread will jump in the first stall available without any regard to other waiting threads.
+Waiting for the first stall (resource) available without spinning is an example of \gls{synch_multiplex}, the ability to wait synchronously for a resource or set of resources.
+Each stall has their own lock since only one person may occupy a stall at a time.
+The standard way that humans solve this problem is that they check if the stalls are occupied and if they all are they queue and watch the stalls until one is free and then enter and lock the stall.
+This solution is simple in real life, but can be difficult to implement in a concurrent context as it requires the threads to somehow wait on all the stalls at the same time.
+The naive solution to this is for each thread to spin indefinitely continually checking the stalls until one is free.
+This wastes cycles and also results in no fairness among threads waiting for stalls as a thread will jump in the first stall available without any regard to other waiting threads.
+The ability to wait for the first stall available without spinning can be done with concurrent tools that provide \gls{synch_multiplex}, the ability to wait synchronously for a resource or set of resources.
 \section{History of Synchronous Multiplexing}
 There is a history of tools that provide \gls{synch_multiplex}.
+Some well known \gls{synch_multiplex} tools include unix system utilities: select(2)\cite{linux:select}, poll(2)\cite{linux:poll}, and epoll(7)\cite{linux:epoll}, and the select statement provided by Go\cite{go:selectref}.
+The theory surrounding \gls{synch_multiplex} was largely introduced by Hoare in his 1985 CSP book \cite{Hoare85} and his later work with Roscoe on the theoretical language Occam\cite{Roscoe88}.
+Some of the most well known include the set of unix system utilities: select(2)\cite{linux:select}, poll(2)\cite{linux:poll}, and epoll(7)\cite{linux:epoll}, and the select statement provided by Go\cite{go:selectref}.
+Before one can examine the history of \gls{synch_multiplex} implementations in detail, the preceding theory must be discussed.
+The theory surrounding this topic was largely introduced by Hoare in his 1985 CSP book \cite{Hoare85} and his later work with Roscoe on the theoretical language Occam\cite{Roscoe88}.
+Both include guards for communication channels and the ability to wait for a single channel to be ready out of a set of channels.
 The work on Occam in \cite{Roscoe88} calls their \gls{synch_multiplex} primitive ALT, which waits for one resource to be available and then executes a corresponding block of code.
+Waiting for one resource out of a set of resources can be thought of as a logical exclusive-or over the set of resources.
+Both CSP and Occam include \Newterm{guards} for communication channels and the ability to wait for a single channel to be ready out of a set of channels.
+Waiting for one resource out of a set of resources can be thought of as a logical exclusive or over the set of resources.
 Guards are a conditional operator similar to an @if@, except they apply to the resource being waited on.
 If a guard is false then the resource it guards is considered to not be in the set of resources being waited on.
 Guards can be simulated using if statements, but to do so requires \[2^N\] if statements, where @N@ is the number of guards.
+Guards can be simulated using if statements, but to do so requires \[2^N\] if cases, where @N@ is the number of guards.
 The equivalence between guards and exponential if statements comes from an Occam ALT statement rule~\cite{Roscoe88}, which is presented in \CFA syntax in Figure~\ref{f:wu_if}.
 Providing guards allows for easy toggling of waituntil clauses without introducing repeated code.
 …
 \begin{figure}
 \begin{cfa}
+// CFA's guards use the keyword 'when'
+when( predicate ) waituntil( A ) {}
+when( predicate ) waituntil( A ) {}
 or waituntil( B ) {}
 // ===
 …
 \end{figure}
 When discussing \gls{synch_multiplex} implementations, one must discuss the resources being multiplexed.
 While the aforementioned theory waits on channels, the earliest known implementation of a synchronous multiplexing tool, Unix's select(2)\cite{linux:select}, is multiplexed over file descriptors.
 The select(2) system call is passed three sets of file descriptors (read, write, exceptional) to wait on and an optional timeout.
 Select(2) will block until either some subset of file descriptors are available or the timeout expires.
 All file descriptors that are ready will be returned by modifying the argument sets to only contain the ready descriptors.
 This early implementation differs from the theory presented in Occam and CSP; when the call from select(2) returns it may provide more than one ready file descriptor.
 As such, select(2) has logical-or multiplexing semantics, whereas the theory described exclusive-or semantics.
+Switching to implementations, it is important to discuss the resources being multiplexed.
+While the aforementioned theory discusses waiting on channels, the earliest known implementation of a synchronous multiplexing tool, Unix's select(2), is multiplexed over file descriptors.
+The select(2) system call takes in sets of file descriptors to wait on as arguments and an optional timeout.
+Select will block until either some subset of file descriptors are available or the timeout expires.
+All file descriptors that are ready will be returned.
+This early implementation differs from the theory as when the call from select returns it may provide more than one ready file descriptor.
+As such select has a logical or multiplexing semantics, whereas the theory described exclusive-or semantics.
 This is not a drawback.
 A user can easily achieve exclusive-or semantics with select by arbitrarily choosing only one of the returned descriptors to operate on.
 Select(2) was followed by poll(2), which was later followed by epoll(7), with each successor improving upon drawbacks in their predecessors.
 The syscall poll(2) improved on select(2) by allowing users to monitor descriptors with numbers higher than 1024 which was not supported by select.
 Epoll(7) then improved on poll(2) to return the set of file descriptors; when one or more descriptors became available poll(2) would return the number of availables descriptors, but would not indicate which descriptors were ready.
+Select was followed by poll(2), and later epoll(7), which both improved upon drawbacks in their predecessors.
+The syscall poll(2) improved on select by allowing users to monitor descriptors with numbers higher than 1024 which was not supported by select.
+Epoll then improved on poll to return the set of file descriptors since poll would only say that some descriptor from the set was ready but not return which ones were ready.
 It is worth noting these \gls{synch_multiplex} tools mentioned so far interact directly with the operating system and are often used to communicate between processes.
 Later, \gls{synch_multiplex} started to appear in user-space to support fast multiplexed concurrent communication between threads.
+Later \gls{synch_multiplex} started to appear in user-space to support fast multiplexed concurrent communication between threads.
 An early example of \gls{synch_multiplex} is the select statement in Ada~\cite[\S~9.7]{Ichbiah79}.
 The select statement in Ada allows a task to multiplex over some subset of its own methods that it would like to @accept@ calls to.
 Tasks in Ada are essentially objects that have their own thread, and as such have methods, fields, etc.
 The Ada select statement has the same exclusive-or semantics and guards as ALT from Occam, however it multiplexes over methods on rather than multiplexing over channels.
 A code block is associated with each @accept@, and the method that is accepted first has its corresponding code block run after the task unblocks.
+Tasks in Ada can be thought of as threads which are an object of a specific class, and as such have methods, fields, etc.
+This statement has the same exclusive-or semantics as ALT from Occam, and supports guards as described in Occam, however it multiplexes over methods on rather than multiplexing over channels.
+A code block is associated with each @accept@, and the method that is @accept@ed first has its corresponding code block run after the task unblocks.
 In this way the select statement in Ada provides rendezvous points for threads, rather than providing some resource through message passing.
 The select statement in Ada also supports an optional timeout with the same semantics as select(2), and provides an @else@.
 …
 Go provides a timeout utility and also provides a @default@ clause which has the same semantics as Ada's @else@ clause.
 \uC provides \gls{synch_multiplex} over futures with their @_Select@ statement and Ada-style \gls{synch_multiplex} over monitor and task methods with their @_Accept@ statement~\cite{uC++}.
+\uC provides \gls{synch_multiplex} over futures with their @_Select@ statement and Ada-style \gls{synch_multiplex} over monitor methods with their @_Accept@ statement~\cite{uC++}.
 Their @_Accept@ statement builds upon the select statement offered by Ada, by offering both @and@ and @or@ semantics, which can be used together in the same statement.
 These semantics are also supported for \uC's @_Select@ statement.
 …
 There are many other languages that provide \gls{synch_multiplex}, including Rust's @select!@ over futures~\cite{rust:select}, OCaml's @select@ over channels~\cite{ocaml:channel}, and C++14's @when_any@ over futures~\cite{cpp:whenany}.
 Note that while C++14 and Rust provide \gls{synch_multiplex}, their implementations leave much to be desired as they both rely on busy-waiting polling to wait on multiple resources.
+Note that while C++14 and Rust provide \gls{synch_multiplex}, their implemetations leave much to be desired as they both rely on busy-waiting polling to wait on multiple resources.
 \section{Other Approaches to Synchronous Multiplexing}
 To avoid the need for \gls{synch_multiplex}, all communication between threads/processes has to come from a single source.
 One key example is Erlang, in which each process has a single heterogenous mailbox that is the sole source of concurrent communication, removing the need for \gls{synch_multiplex} as there is only one place to wait on resources.
 In a similar vein, actor systems circumvent the \gls{synch_multiplex} problem as actors are traditionally non-blocking, so they will never block in a behaviour and only block when waiting for the next message.
+In a similar vein, actor systems circumvent the \gls{synch_multiplex} problem as actors are traditionally non-blocking, so they will only block when waiting for the next message.
 While these approaches solve the \gls{synch_multiplex} problem, they introduce other issues.
 Consider the case where a thread has a single source of communication (like erlang and actor systems) wants one of a set of @N@ resources.
 …
 The new \CFA \gls{synch_multiplex} utility introduced in this work is the @waituntil@ statement.
 There is a @waitfor@ statement in \CFA that supports Ada-style \gls{synch_multiplex} over monitor methods, so this @waituntil@ focuses on synchronizing over other resources.
 All of the \gls{synch_multiplex} features mentioned so far are monomorphic, only supporting one resource to wait on: select(2) supports file descriptors, Go's select supports channel operations, \uC's select supports futures, and Ada's select supports monitor method calls.
+All of the \gls{synch_multiplex} features mentioned so far are monomorphic, only supporting one resource to wait on, select(2) supports file descriptors, Go's select supports channel operations, \uC's select supports futures, and Ada's select supports monitor method calls.
 The waituntil statement in \CFA is polymorphic and provides \gls{synch_multiplex} over any objects that satisfy the trait in Figure~\ref{f:wu_trait}.
 No other language provides a synchronous multiplexing tool polymorphic over resources like \CFA's waituntil.
+All others them tie themselves to some specific type of resource.
 \begin{figure}
 …
 Currently locks, channels, futures and timeouts are supported by the waituntil statement, but this will be expanded as other use cases arise.
 The @waituntil@ statement supports guarded clauses, like Ada, and Occam, supports both @or@, and @and@ semantics, like \uC, and provides an @else@ for asynchronous multiplexing. An example of \CFA waituntil usage is shown in Figure~\ref{f:wu_example}. In Figure~\ref{f:wu_example} the waituntil statement is waiting for either @Lock@ to be available or for a value to be read from @Channel@ into @i@ and for @Future@ to be fulfilled.
+The waituntil statement supports guarded clauses, like Ada, and Occam, supports both @or@, and @and@ semantics, like \uC, and provides an @else@ for asynchronous multiplexing. An example of \CFA waituntil usage is shown in Figure~\ref{f:wu_example}. In Figure~\ref{f:wu_example} the waituntil statement is waiting for either @Lock@ to be available or for a value to be read from @Channel@ into @i@ and for @Future@ to be fulfilled. The semantics of the waituntil statement will be discussed in detail in the next section.
 \begin{figure}
 …
 \section{Waituntil Semantics}
 There are two parts of the waituntil semantics to discuss, the semantics of the statement itself, \ie @and@, @or@, @when@ guards, and @else@ semantics, and the semantics of how the waituntil interacts with types like channels, locks and futures.
+To start, the semantics of the statement itself will be discussed.
 \subsection{Waituntil Statement Semantics}
 The @or@ semantics are the most straightforward and nearly match those laid out in the ALT statement from Occam, the clauses have an exclusive-or relationship where the first one to be available will be run and only one clause is run.
 \CFA's @or@ semantics differ from ALT semantics in one respect, instead of randomly picking a clause when multiple are available, the clause that appears first in the order of clauses will be picked.
 \eg in the following example, if @foo@ and @bar@ are both available, @foo@ will always be selected since it comes first in the order of @waituntil@ clauses.
+\eg in the following example, if @foo@ and @bar@ are both available, @foo@ will always be selected since it comes first in the order of waituntil clauses.
 \begin{cfa}
 future(int) bar;
 …
 The @and@ semantics match the @and@ semantics used by \uC.
 When multiple clauses are joined by @and@, the @waituntil@ will make a thread wait for all to be available, but will run the corresponding code blocks \emph{as they become available}.
+When multiple clauses are joined by @and@, the waituntil will make a thread wait for all to be available, but will run the corresponding code blocks \emph{as they become available}.
 As @and@ clauses are made available, the thread will be woken to run those clauses' code blocks and then the thread will wait again until all clauses have been run.
 This allows work to be done in parallel while synchronizing over a set of resources, and furthermore gives a good reason to use the @and@ operator.
 …
 The guards in the waituntil statement are called @when@ clauses.
+Each the boolean expression inside a @when@ is evaluated once before the waituntil statement is run.
+The @when@ clause is passed a boolean expression.
+All the @when@ boolean expressions are evaluated before the waituntil statement is run.
 The guards in Occam's ALT effectively toggle clauses on and off, where a clause will only be evaluated and waited on if the corresponding guard is @true@.
 The guards in the waituntil statement operate the same way, but require some nuance since both @and@ and @or@ operators are supported.
-This will be discussed further in Section~\ref{s:wu_guards}.
 When a guard is false and a clause is removed, it can be thought of as removing that clause and its preceding operator from the statement.
 \eg in the following example the two waituntil statements are semantically the same.
 …
 The waituntil statement expects types to register and unregister themselves via calls to @register_select@ and @unregister_select@ respectively.
 When a resource becomes available, @on_selected@ is run.
 Many types do not need @on_selected@, but it is provided since some types may need to perform some work or checks before the resource can be accessed in the code block.
+Many types may not need @on_selected@, but it is provided since some types may need to check and set things before the resource can be accessed in the code block.
 The register/unregister routines in the trait return booleans.
 The return value of @register_select@ is @true@ if the resource is immediately available, and @false@ otherwise.
 …
 The waituntil statement is not inherently complex, and can be described as a few steps.
 The complexity of the statement comes from the consideration of race conditions and synchronization needed when supporting various primitives.
+The basic steps of the waituntil statement are the following:
+\begin{enumerate}[topsep=5pt,itemsep=3pt,parsep=0pt]
+\item
+The basic steps that the waituntil statement follows are the following.
 First the waituntil statement creates a @select_node@ per resource that is being waited on.
 The @select_node@ is an object that stores the waituntil data pertaining to one of the resources.
-\item
 Then, each @select_node@ is then registered with the corresponding resource.
+\item
+The thread executing the waituntil then enters a loop that will loop until the @waituntil@ statement's predicate is satisfied.
+The thread executing the waituntil then enters a loop that will loop until the entire waituntil statement being satisfied.
 In each iteration of the loop the thread attempts to block.
 If any clauses are satified the block will fail and the thread will proceed, otherwise the block succeeds.
 After proceeding past the block all clauses are checked for completion and the completed clauses have their code blocks run.
+Once the thread escapes the loop, the @select_nodes@ are unregistered from the resources.
 In the case where the block suceeds, the thread will be woken by the thread that marks one of the resources as available.
-\item
-Once the thread escapes the loop, the @select_nodes@ are unregistered from the resources.
-\end{enumerate}
 Pseudocode detailing these steps is presented in the following code block.
 \begin{cfa}
 select_nodes s[N]; // N select nodes
 for ( node in s )
     register_select( resource, node );
 while( statement predicate not satisfied ) {
+while( statement not satisfied ) {
     // try to block
     for ( resource in waituntil statement )
 …
     unregister_select( resource, node );
 \end{cfa}
+These steps give a basic overview of how the statement works.
+Digging into parts of the implementation will shed light on the specifics and provide more detail.
+These steps give a basic, but mildly inaccurate overview of how the statement works.
+Digging into some parts of the implementation will shed light on more of the specifics and provide some accuracy.
 \subsection{Locks}
 Locks are one of the resources supported by the @waituntil@ statement.
+Locks are one of the resources supported in the waituntil statement.
 When a thread waits on multiple locks via a waituntil, it enqueues a @select_node@ in each of the lock's waiting queues.
 When a @select_node@ reaches the front of the queue and gains ownership of a lock, the blocked thread is notified.
 …
 \end{cfa}
+The timeout implementation highlights a key part of the waituntil semantics, the expression inside a @waituntil()@ is evaluated once at the start of the @waituntil@ algorithm.
+As such, calls to these @sleep@ and @timeout@ routines do not block, but instead return a type that supports the @is_selectable@ trait.
+This feature leverages \CFA's ability to overload on return type; a call to @sleep@ outside a waituntil will call a different @sleep@ that does not return a type, which will block for the appropriate duration.
+This mechanism of returning a selectable type is needed for types that want to support multiple operations such as channels that allow both reading and writing.
+The timeout implementation highlights a key part of the waituntil semantics, the expression is evaluated before the waituntil runs.
+As such calls to @sleep@ and @timeout@ do not block, but instead return a type that supports the @is_selectable@ trait.
+This mechanism is needed for types that want to support multiple operations such as channels that support reading and writing.
 \subsection{Channels}\label{s:wu_chans}
 To support both waiting on both reading and writing to channels, the operators @?<<?@ and @?>>?@ are used read and write to a channel respectively, where the lefthand operand is the value being read into/written and the righthand operand is the channel.
 Channels require significant complexity to synchronously multiplex on for a few reasons.
+First, reading or writing to a channel is a mutating operation;
 If a read or write to a channel occurs, the state of the channel has changed.
 In comparison, for standard locks and futures, if a lock is acquired then released or a future is ready but not accessed, the state of the lock and the future is not permanently modified.
 In this way, a waituntil over locks or futures that completes with resources available but not consumed is not an issue.
+To support both waiting on both reading and writing to channels, the opperators @?<<?@ and @?>>?@ are used to show reading and writing to a channel respectively, where the lefthand operand is the value and the righthand operand is the channel.
+Channels require significant complexity to wait on for a few reasons.
+The first reason is that reading or writing to a channel is a mutating operation.
+What this means is that if a read or write to a channel occurs, the state of the channel has changed.
+In comparison, for standard locks and futures, if a lock is acquired then released or a future is ready but not accessed, the states of the lock and the future are not modified.
+In this way if a waituntil over locks or futures have some resources available that were not consumed, it is not an issue.
 However, if a thread modifies a channel on behalf of a thread blocked on a waituntil statement, it is important that the corresponding waituntil code block is run, otherwise there is a potentially erroneous mismatch between the channel state and associated side effects.
 As such, the @unregister_select@ routine has a boolean return that is used by channels to indicate when the operation was completed but the block was not run yet.
 When the return is @true@, the corresponding code block is run after the unregister.
 Furthermore, if both @and@ and @or@ operators are used, the @or@ operators have to stop behaving like exclusive-or semantics due to the race between channel operations and unregisters.
+As such some channel code blocks may be run as part of the unregister.
+Furthermore if there are both @and@ and @or@ operators, the @or@ operators stop behaving like exclusive-or semantics since this race between operations and unregisters exists.
 It was deemed important that exclusive-or semantics were maintained when only @or@ operators were used, so this situation has been special-cased, and is handled by having all clauses race to set a value \emph{before} operating on the channel.
 …
 However, due to TOCTOU issues, one cannot know that all resources are available without acquiring all the internal locks of channels in the subtree.
 This is not a good solution for two reasons.
 It is possible that once all the locks are acquired the subtree is not satisfied and the locks must all be released.
 This would incur a high cost for signalling threads and heavily increase contention on internal channel locks.
 Furthermore, the @waituntil@ statement is polymorphic and can support resources that do not have internal locks, which also makes this approach infeasible.
+It is possible that once all the locks are acquired that the subtree is not satisfied and they must all be released.
+This would incur high cost for signalling threads and also heavily increase contention on internal channel locks.
+Furthermore, the waituntil statement is polymorphic and can support resources that do not have internal locks, which also makes this approach infeasible.
 As such, the exclusive-or semantics are lost when using both @and@ and @or@ operators since they can not be supported without significant complexity and hits to waituntil statement performance.
 Channels introduce another interesting consideration in their implementation.
+Supporting both reading and writing to a channel in A @waituntil@ means that one @waituntil@ clause may be the notifier for another @waituntil@ clause.
 This poses a problem when dealing with the special-cased @or@ where the clauses need to win a race to operate on a channel.
 When both a special-case @or@ is inserting to a channel on one thread and another thread is blocked in a special-case @or@ consuming from the same channel there is not one but two races that need to be consolidated by the inserting thread.
+(This race can also occur in the mirrored case with a blocked producer and signalling consumer.)
+For the producing thread to know that the insert succeeded, they need to win the race for their own waituntil and win the race for the other waituntil.
+The mechanism by which the predicate of the waituntil is checked is discussed in more detail in Section~\ref{s:wu_guards}.
+Another consideration introduced by channels is that supporting both reading and writing to a channel in a waituntil means that one waituntil clause may be the notifier for another waituntil clause.
+This becomes a problem when dealing with the special-cased @or@ where the clauses need to win a race to operate on a channel.
+When you have both a special-case @or@ inserting on one thread and another special-case @or@ consuming is blocked on another thread there is not one but two races that need to be consolidated by the inserting thread.
+(The race can occur in the opposite case with a blocked producer and signalling consumer too.)
+For them to know that the insert succeeded, they need to win the race for their own waituntil and win the race for the other waituntil.
 Go solves this problem in their select statement by acquiring the internal locks of all channels before registering the select on the channels.
 This eliminates the race since no other threads can operate on the blocked channel since its lock will be held.
 This approach is not used in \CFA since the waituntil is polymorphic.
 Not all types in a waituntil have an internal lock, and when using non-channel types acquiring all the locks incurs extra uneeded overhead.
 Instead this race is consolidated in \CFA in two phases by having an intermediate pending status value for the race.
 This race case is detectable, and if detected the thread attempting to signal will first race to set the race flag to be pending.
+This case is detectable, and if detected the thread attempting to signal will first race to set the race flag to be pending.
 If it succeeds, it then attempts to set the consumer's race flag to its success value.
 If the producer successfully sets the consumer race flag, then the operation can proceed, if not the signalling thread will set its own race flag back to the initial value.
 …
 In \uC and \CFA, their \gls{synch_multiplex} utilities involve both an @and@ and @or@ operator, which make the problem of checking for completion of the statement more difficult.
 In the \uC @_Select@ statement, this problem is solved by constructing a tree of the resources, where the internal nodes are operators and the leaves are booleans storing the state of each resource.
 The internal nodes also store the statuses of the two subtrees beneath them.
 When resources become available, their corresponding leaf node status is modified and then percolates up into the internal nodes to update the state of the statement.
+In the \uC @_Select@ statement, they solve this problem by constructing a tree of the resources, where the internal nodes are operators and the leafs are the resources.
+The internal nodes also store the status of each of the subtrees beneath them.
+When resources become available, their status is modified and the status of the leaf nodes percolate into the internal nodes update the state of the statement.
 Once the root of the tree has both subtrees marked as @true@ then the statement is complete.
 As an optimization, when the internal nodes are updated, their subtrees marked as @true@ are pruned and are not touched again.
 To support statement guards in \uC, the tree prunes a branch if the corresponding guard is false.
+As an optimization, when the internal nodes are updated, their subtrees marked as @true@ are effectively pruned and are not touched again.
+To support \uC's @_Select@ statement guards, the tree prunes the branch if the guard is false.
 The \CFA waituntil statement blocks a thread until a set of resources have become available that satisfy the underlying predicate.
 The waiting condition of the waituntil statement can be represented as a predicate over the resources, joined by the waituntil operators, where a resource is @true@ if it is available, and @false@ otherwise.
 In \CFA, this representation is used as the mechanism to check if a thread is done waiting on the waituntil.
 Leveraging the compiler, a predicate routine is generated per waituntil that when passed the statuses of the resources, returns @true@ when the waituntil is done, and false otherwise.
 To support guards on the \CFA waituntil statement, the status of a resource disabled by a guard is set to a boolean value that ensures that the predicate function behaves as if that resource is no longer part of the predicate.
 \uC's @_Select@, supports operators both inside and outside of the clauses.
+Leveraging the compiler, a routine is generated per waituntil that is passed the statuses of the resources and returns a boolean that is @true@ when the waituntil is done, and false otherwise.
+To support guards on the \CFA waituntil statement, the status of a resource disabled by a guard is set to ensure that the predicate function behaves as if that resource is no longer part of the predicate.
+In \uC's @_Select@, it supports operators both inside and outside the clauses of their statement.
 \eg in the following example the code blocks will run once their corresponding predicate inside the round braces is satisfied.
 …
 This is more expressive that the waituntil statement in \CFA.
 In \CFA, since the waituntil statement supports more resources than just futures, implementing operators inside clauses was avoided for a few reasons.
 As a motivating example, suppose \CFA supported operators inside clauses and consider the code snippet in Figure~\ref{f:wu_inside_op}.
+In \CFA, since the waituntil statement supports more resources than just futures, implmenting operators inside clauses was avoided for a few reasons.
+As an example, suppose \CFA supported operators inside clauses and consider the code snippet in Figure~\ref{f:wu_inside_op}.
 \begin{figure}
 …
 If the waituntil in Figure~\ref{f:wu_inside_op} works with the same semantics as described and acquires each lock as it becomes available, it opens itself up to possible deadlocks since it is now holding locks and waiting on other resources.
 Other semantics would be needed to ensure that this operation is safe.
+As such other semantics would be needed to ensure that this operation is safe.
 One possibility is to use \CC's @scoped_lock@ approach that was described in Section~\ref{s:DeadlockAvoidance}, however the potential for livelock leaves much to be desired.
 Another possibility would be to use resource ordering similar to \CFA's @mutex@ statement, but that alone is not sufficient if the resource ordering is not used everywhere.
 …
 If all the locks are available, it becomes complex to both respect the ordering of the waituntil in Figure~\ref{f:wu_inside_op} when choosing which code block to run and also respect the lock ordering of @D@, @B@, @C@, @A@ at the same time.
 One other way this could be implemented is to wait until all resources for a given clause are available before proceeding to acquire them, but this also quickly becomes a poor approach.
 This approach won't work due to TOCTOU issues; it is not possible to ensure that the full set resources are available without holding them all first.
+This approach won't work due to TOCTOU issues, as it is not possible to ensure that the full set resources are available without holding them all first.
 Operators inside clauses in \CFA could potentially be implemented with careful circumvention of the problems involved, but it was not deemed an important feature when taking into account the runtime cost that would need to be paid to handle these situations.
 The problem of operators inside clauses also becomes a difficult issue to handle when supporting channels.
 If internal operators were supported, it would require some way to ensure that channels used with internal operators are modified on if and only if the corresponding code block is run, but that is not feasible due to reasons described in the exclusive-or portion of Section~\ref{s:wu_chans}.
+If internal operators were supported, it would require some way to ensure that channels with internal operators are modified on if and only if the corresponding code block is run, but that is not feasible due to reasons described in the exclusive-or portion of Section~\ref{s:wu_chans}.
 \section{Waituntil Performance}
 …
 The similar utilities discussed at the start of this chapter in C, Ada, Rust, \CC, and OCaml are either not meaningful or feasible to benchmark against.
 The select(2) and related utilities in C are not comparable since they are system calls that go into the kernel and operate on file descriptors, whereas the waituntil exists solely in userspace.
 Ada's @select@ only operates on methods, which is done in \CFA via the @waitfor@ utility so it is not meaningful to benchmark against the @waituntil@, which cannot wait on the same resource.
 Rust and \CC only offer a busy-wait based approach which is not comparable to a blocking approach.
 OCaml's @select@ waits on channels that are not comparable with \CFA and Go channels, so OCaml @select@ is not benchmarked against Go's @select@ and \CFA's @waituntil@.
 Given the differences in features, polymorphism, and expressibility between @waituntil@ and @select@, and @_Select@, the aim of the microbenchmarking in this chapter is to show that these implementations lie in the same realm of performance, not to pick a winner.
+Ada's @select@ only operates on methods, which is done in \CFA via the @waitfor@ utility so it is not feasible to benchmark against the @waituntil@, which cannot wait on the same resource.
+Rust and \CC only offer a busy-wait based approach which is not meaningly comparable to a blocking approach.
+OCaml's @select@ waits on channels that are not comparable with \CFA and Go channels, which makes the OCaml @select@ infeasible to compare it with Go's @select@ and \CFA's @waituntil@.
+Given the differences in features, polymorphism, and expressibility between the waituntil and @select@, and @_Select@, the aim of the microbenchmarking in this chapter is to show that these implementations lie in the same realm of performance, not to pick a winner.
 \subsection{Channel Benchmark}

doc/theses/colby_parsons_MMAth/thesis.tex

r4c2e561	r3397eed
206	206	\input{waituntil}
207	207
208		~~\input{conclusion}~~
209
210	208	%----------------------------------------------------------------------
211	209	% END MATERIAL

src/Common/ScopedMap.h

-              r4c2e561
+              r3397eed
         friend class ScopedMap;
         friend class const_iterator;
+        typedef typename MapType::iterator wrapped_iterator;
+        typedef typename ScopeList::size_type size_type;
+        typedef typename ScopedMap::MapType::iterator wrapped_iterator;
+        typedef typename ScopedMap::ScopeList scope_list;
+        typedef typename scope_list::size_type size_type;
         /// Checks if this iterator points to a valid item
 …
+        }
         iterator(ScopeList & _scopes, const wrapped_iterator & _it, size_type inLevel)
+        iterator(scope_list & _scopes, const wrapped_iterator & _it, size_type inLevel)
                 : scopes(&_scopes), it(_it), level(inLevel) {}
 public:
 …
 private:
         ScopeList *scopes;
+        scope_list *scopes;
         wrapped_iterator it;
         size_type level;

src/Concurrency/KeywordsNew.cpp

-              r4c2e561
+              r3397eed
 void ConcurrentSueKeyword::addGetRoutines(
                 const ast::ObjectDecl * field, const ast::FunctionDecl * forward ) {
-        // Clone the signature and then build the body.
-        ast::FunctionDecl * decl = ast::deepCopy( forward );
         // Say it is generated at the "same" places as the forward declaration.
         const CodeLocation & location = decl->location;
         const ast::DeclWithType * param = decl->params.front();
+        const CodeLocation & location = forward->location;
+        const ast::DeclWithType * param = forward->params.front();
         ast::Stmt * stmt = new ast::ReturnStmt( location,
                 new ast::AddressExpr( location,
 …
         );
+        ast::FunctionDecl * decl = ast::deepCopy( forward );
         decl->stmts = new ast::CompoundStmt( location, { stmt } );
         declsToAddAfter.push_back( decl );

src/GenPoly/ErasableScopedMap.h

-              r4c2e561
+              r3397eed
         /// Starts a new scope
         void beginScope() {
+                scopes.emplace_back();
+                Scope scope;
+                scopes.push_back(scope);
+        }
 …
                 public std::iterator< std::bidirectional_iterator_tag, value_type > {
         friend class ErasableScopedMap;
+        typedef typename Scope::iterator wrapped_iterator;
+        typedef typename ScopeList::size_type size_type;
+        typedef typename std::map< Key, Value >::iterator wrapped_iterator;
+        typedef typename std::vector< std::map< Key, Value > > scope_list;
+        typedef typename scope_list::size_type size_type;
         /// Checks if this iterator points to a valid item

src/GenPoly/ScopedSet.h

-              r4c2e561
+              r3397eed
         /// Starts a new scope
         void beginScope() {
+                scopes.emplace_back();
+                Scope scope;
+                scopes.push_back(scope);
+        }
 …
         iterator findNext( const_iterator &it, const Value &key ) {
                 if ( it.i == 0 ) return end();
                 for ( size_type i = it.i - 1; ; --i ) {
+                        for ( size_type i = it.i - 1; ; --i ) {
                         typename Scope::iterator val = scopes[i].find( key );
                         if ( val != scopes[i].end() ) return iterator( scopes, val, i );
 …
         friend class ScopedSet;
         friend class const_iterator;
+        typedef typename Scope::iterator wrapped_iterator;
+        typedef typename ScopeList::size_type size_type;
+        typedef typename std::set< Value >::iterator wrapped_iterator;
+        typedef typename std::vector< std::set< Value > > scope_list;
+        typedef typename scope_list::size_type size_type;
         /// Checks if this iterator points to a valid item
 …
+        }
         iterator(ScopeList const &_scopes, const wrapped_iterator &_it, size_type _i)
+        iterator(scope_list const &_scopes, const wrapped_iterator &_it, size_type _i)
                 : scopes(&_scopes), it(_it), i(_i) {}
 public:
 …
 private:
         ScopeList const *scopes;
+        scope_list const *scopes;
         wrapped_iterator it;
         size_type i;
 …
                 public std::iterator< std::bidirectional_iterator_tag, value_type > {
         friend class ScopedSet;
+        typedef typename Scope::iterator wrapped_iterator;
+        typedef typename Scope::const_iterator wrapped_const_iterator;
+        typedef typename ScopeList::size_type size_type;
+        typedef typename std::set< Value >::iterator wrapped_iterator;
+        typedef typename std::set< Value >::const_iterator wrapped_const_iterator;
+        typedef typename std::vector< std::set< Value > > scope_list;
+        typedef typename scope_list::size_type size_type;
         /// Checks if this iterator points to a valid item
 …
+        }
         const_iterator(ScopeList const &_scopes, const wrapped_const_iterator &_it, size_type _i)
+        const_iterator(scope_list const &_scopes, const wrapped_const_iterator &_it, size_type _i)
                 : scopes(&_scopes), it(_it), i(_i) {}
 public:
 …
 private:
         ScopeList const *scopes;
+        scope_list const *scopes;
         wrapped_const_iterator it;
         size_type i;

src/SymTab/FixFunction.cc

-              r4c2e561
+              r3397eed
                 const ast::DeclWithType * postvisit( const ast::FunctionDecl * func ) {
+                        // Cannot handle cases with asserions.
+                        assert( func->assertions.empty() );
+                        return new ast::ObjectDecl{
+                                func->location, func->name, new ast::PointerType( func->type ), nullptr,
+                        return new ast::ObjectDecl{
+                                func->location, func->name, new ast::PointerType{ func->type }, nullptr,
                                 func->storage, func->linkage, nullptr, copy( func->attributes ) };
+                }
 …
                 const ast::Type * postvisit( const ast::ArrayType * array ) {
                         return new ast::PointerType{
                                 array->base, array->dimension, array->isVarLen, array->isStatic,
+                        return new ast::PointerType{
+                                array->base, array->dimension, array->isVarLen, array->isStatic,
                                 array->qualifiers };
+                }

Context Navigation

Changes in / [4c2e561:3397eed]

Legend:

doc/theses/colby_parsons_MMAth/Makefile

doc/theses/colby_parsons_MMAth/local.bib

doc/theses/colby_parsons_MMAth/text/channels.tex

doc/theses/colby_parsons_MMAth/text/conclusion.tex

doc/theses/colby_parsons_MMAth/text/intro.tex

doc/theses/colby_parsons_MMAth/text/waituntil.tex

doc/theses/colby_parsons_MMAth/thesis.tex

src/Common/ScopedMap.h

src/Concurrency/KeywordsNew.cpp

src/GenPoly/ErasableScopedMap.h

src/GenPoly/ScopedSet.h

src/SymTab/FixFunction.cc

Download in other formats: