Changeset aae9c17 for doc/theses/colby_parsons_MMAth/text/channels.tex
- Timestamp:
- Sep 5, 2023, 5:48:31 PM (13 months ago)
- Branches:
- master
- Children:
- 1f10959, efe39bb
- Parents:
- f54e6ec
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/colby_parsons_MMAth/text/channels.tex
rf54e6ec raae9c17 39 39 Zero sized implies the communication is synchronous, \ie the producer must wait for the consumer to arrive or vice versa for a value to be communicated. 40 40 \item 41 Fixed sized (bounded) implies the communication is asynchronous, \ie the producer can proceed up to the buffer size and vice versa for the consumer with respect to removal.41 Fixed sized (bounded) implies the communication is mostly asynchronous, \ie the producer can proceed up to the buffer size and vice versa for the consumer with respect to removal, at which point the producer/consumer would wait. 42 42 \item 43 43 Infinite sized (unbounded) implies the communication is asynchronous, \ie the producer never waits but the consumer waits when the buffer is empty. … … 66 66 67 67 \section{Channel Implementation}\label{s:chan_impl} 68 Currently, only the Go programming language provides user-level threading where the primary communication mechanism is channels. 69 Experiments were conducted that varied the producer-consumer algorithm and lock type used inside the channel. 68 Currently, only the Go and Erlang programming languages provide user-level threading where the primary communication mechanism is channels. 69 Both Go and Erlang have user-level threading and preemptive scheduling, and both use channels for communication. 70 Go provides multiple homogeneous channels; each have a single associated type. 71 Erlang, which is closely related to actor systems, provides one heterogeneous channel per thread (mailbox) with a typed receive pattern. 72 Go encourages users to communicate via channels, but provides them as an optional language feature. 73 On the other hand, Erlang's single heterogeneous channel is a fundamental part of the threading system design; using it is unavoidable. 74 Similar to Go, \CFA's channels are offered as an optional language feature. 75 76 While iterating on channel implementation, experiments were conducted that varied the producer-consumer algorithm and lock type used inside the channel. 70 77 With the exception of non-\gls{fcfs} or non-\gls{fifo} 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. 71 78 Performance of channels can be improved by sharding the underlying buffer \cite{Dice11}. … … 82 89 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. 83 90 The other advantage of Go's wait-morphing approach is that it eliminates the bottleneck of waiting for signalled threads to run. 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}.91 Note that the property of acquiring/releasing the lock only once can also be achieved with a different form of cooperation, called \Newterm{baton passing}. 85 92 Baton passing occurs when one thread acquires a lock but does not release it, and instead signals a thread inside the critical section, conceptually ``passing'' the mutual exclusion from the signalling thread to the signalled thread. 86 93 The baton-passing approach has threads cooperate to pass mutual exclusion without additional lock acquires or releases; … … 147 154 Thus, improperly handled \gls{toctou} issues with channels often result in deadlocks as threads performing the termination may end up unexpectedly blocking in their attempt to help other threads exit the system. 148 155 149 \paragraph{Go channels}provide a set of tools to help with concurrent shutdown~\cite{go:chan} using a @close@ operation in conjunction with the \Go{select} statement.156 Go channels provide a set of tools to help with concurrent shutdown~\cite{go:chan} using a @close@ operation in conjunction with the \Go{select} statement. 150 157 The \Go{select} statement is discussed in \ref{s:waituntil}, where \CFA's @waituntil@ statement is compared with the Go \Go{select} statement. 151 158 … … 159 166 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. 160 167 If errors need to occur in Go, return codes are used to pass error information up call levels. 161 Note ,panics in Go can be caught, but it is not the idiomatic way to write Go programs.168 Note that panics in Go can be caught, but it is not the idiomatic way to write Go programs. 162 169 163 170 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. … … 451 458 The results of the benchmark are shown in Figure~\ref{f:chanPerf}. 452 459 The performance of Go and \CFA channels on this microbenchmark is comparable. 453 Note, the performance should decline as the number of cores increases as the channel operations occur in a critical section, so increasing cores results in higher contention with no increase in parallelism. 460 Note that the performance should decline as the number of cores increases as the channel operations occur in a critical section, so increasing cores results in higher contention with no increase in parallelism. 461 462 The performance of \CFA and Go's shutdown mechanisms is not measured, as shutdown is an exceptional case that does not occur frequently in most programs. Additionally, it is difficult to measure channel shutdown performance; threads need to be synchronized between each subsequent shutdown, which is likely more expensive than the shutdown mechanism itself. 454 463 455 464 \begin{figure} 456 465 \centering 457 \subfloat[AMD \CFAChannel Benchmark]{466 \subfloat[AMD Channel Benchmark]{ 458 467 \resizebox{0.5\textwidth}{!}{\input{figures/nasus_Channel_Contention.pgf}} 459 468 \label{f:chanAMD} 460 469 } 461 \subfloat[Intel \CFAChannel Benchmark]{470 \subfloat[Intel Channel Benchmark]{ 462 471 \resizebox{0.5\textwidth}{!}{\input{figures/pyke_Channel_Contention.pgf}} 463 472 \label{f:chanIntel}
Note: See TracChangeset
for help on using the changeset viewer.