1<html> 2<head> 3<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 4<title>The Proactor Design Pattern: Concurrency Without Threads</title> 5<link rel="stylesheet" href="../../../../../doc/src/boostbook.css" type="text/css"> 6<meta name="generator" content="DocBook XSL Stylesheets V1.79.1"> 7<link rel="home" href="../../../boost_asio.html" title="Boost.Asio"> 8<link rel="up" href="../core.html" title="Core Concepts and Functionality"> 9<link rel="prev" href="basics.html" title="Basic Boost.Asio Anatomy"> 10<link rel="next" href="threads.html" title="Threads and Boost.Asio"> 11</head> 12<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> 13<table cellpadding="2" width="100%"><tr> 14<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../boost.png"></td> 15<td align="center"><a href="../../../../../index.html">Home</a></td> 16<td align="center"><a href="../../../../../libs/libraries.htm">Libraries</a></td> 17<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> 18<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> 19<td align="center"><a href="../../../../../more/index.htm">More</a></td> 20</tr></table> 21<hr> 22<div class="spirit-nav"> 23<a accesskey="p" href="basics.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../core.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../../boost_asio.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="threads.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> 24</div> 25<div class="section"> 26<div class="titlepage"><div><div><h4 class="title"> 27<a name="boost_asio.overview.core.async"></a><a class="link" href="async.html" title="The Proactor Design Pattern: Concurrency Without Threads">The Proactor Design 28 Pattern: Concurrency Without Threads</a> 29</h4></div></div></div> 30<p> 31 The Boost.Asio library offers side-by-side support for synchronous and 32 asynchronous operations. The asynchronous support is based on the Proactor 33 design pattern <a class="link" href="async.html#boost_asio.overview.core.async.references">[POSA2]</a>. 34 The advantages and disadvantages of this approach, when compared to a synchronous-only 35 or Reactor approach, are outlined below. 36 </p> 37<h6> 38<a name="boost_asio.overview.core.async.h0"></a> 39 <span class="phrase"><a name="boost_asio.overview.core.async.proactor_and_boost_asio"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.proactor_and_boost_asio">Proactor 40 and Boost.Asio</a> 41 </h6> 42<p> 43 Let us examine how the Proactor design pattern is implemented in Boost.Asio, 44 without reference to platform-specific details. 45 </p> 46<p> 47 <span class="inlinemediaobject"><img src="../../proactor.png" alt="proactor"></span> 48 </p> 49<p> 50 <span class="bold"><strong>Proactor design pattern (adapted from [POSA2])</strong></span> 51 </p> 52<p> 53 — Asynchronous Operation 54 </p> 55<div class="blockquote"><blockquote class="blockquote"><p> 56 Defines an operation that is executed asynchronously, such as an asynchronous 57 read or write on a socket. 58 </p></blockquote></div> 59<p> 60 — Asynchronous Operation Processor 61 </p> 62<div class="blockquote"><blockquote class="blockquote"><p> 63 Executes asynchronous operations and queues events on a completion event 64 queue when operations complete. From a high-level point of view, internal 65 services like <code class="computeroutput"><span class="identifier">reactive_socket_service</span></code> 66 are asynchronous operation processors. 67 </p></blockquote></div> 68<p> 69 — Completion Event Queue 70 </p> 71<div class="blockquote"><blockquote class="blockquote"><p> 72 Buffers completion events until they are dequeued by an asynchronous 73 event demultiplexer. 74 </p></blockquote></div> 75<p> 76 — Completion Handler 77 </p> 78<div class="blockquote"><blockquote class="blockquote"><p> 79 Processes the result of an asynchronous operation. These are function 80 objects, often created using <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">bind</span></code>. 81 </p></blockquote></div> 82<p> 83 — Asynchronous Event Demultiplexer 84 </p> 85<div class="blockquote"><blockquote class="blockquote"><p> 86 Blocks waiting for events to occur on the completion event queue, and 87 returns a completed event to its caller. 88 </p></blockquote></div> 89<p> 90 — Proactor 91 </p> 92<div class="blockquote"><blockquote class="blockquote"><p> 93 Calls the asynchronous event demultiplexer to dequeue events, and dispatches 94 the completion handler (i.e. invokes the function object) associated 95 with the event. This abstraction is represented by the <code class="computeroutput"><span class="identifier">io_context</span></code> class. 96 </p></blockquote></div> 97<p> 98 — Initiator 99 </p> 100<div class="blockquote"><blockquote class="blockquote"><p> 101 Application-specific code that starts asynchronous operations. The initiator 102 interacts with an asynchronous operation processor via a high-level interface 103 such as <code class="computeroutput"><span class="identifier">basic_stream_socket</span></code>, 104 which in turn delegates to a service like <code class="computeroutput"><span class="identifier">reactive_socket_service</span></code>. 105 </p></blockquote></div> 106<h6> 107<a name="boost_asio.overview.core.async.h1"></a> 108 <span class="phrase"><a name="boost_asio.overview.core.async.implementation_using_reactor"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.implementation_using_reactor">Implementation 109 Using Reactor</a> 110 </h6> 111<p> 112 On many platforms, Boost.Asio implements the Proactor design pattern in 113 terms of a Reactor, such as <code class="computeroutput"><span class="identifier">select</span></code>, 114 <code class="computeroutput"><span class="identifier">epoll</span></code> or <code class="computeroutput"><span class="identifier">kqueue</span></code>. This implementation approach 115 corresponds to the Proactor design pattern as follows: 116 </p> 117<p> 118 — Asynchronous Operation Processor 119 </p> 120<div class="blockquote"><blockquote class="blockquote"><p> 121 A reactor implemented using <code class="computeroutput"><span class="identifier">select</span></code>, 122 <code class="computeroutput"><span class="identifier">epoll</span></code> or <code class="computeroutput"><span class="identifier">kqueue</span></code>. When the reactor indicates 123 that the resource is ready to perform the operation, the processor executes 124 the asynchronous operation and enqueues the associated completion handler 125 on the completion event queue. 126 </p></blockquote></div> 127<p> 128 — Completion Event Queue 129 </p> 130<div class="blockquote"><blockquote class="blockquote"><p> 131 A linked list of completion handlers (i.e. function objects). 132 </p></blockquote></div> 133<p> 134 — Asynchronous Event Demultiplexer 135 </p> 136<div class="blockquote"><blockquote class="blockquote"><p> 137 This is implemented by waiting on an event or condition variable until 138 a completion handler is available in the completion event queue. 139 </p></blockquote></div> 140<h6> 141<a name="boost_asio.overview.core.async.h2"></a> 142 <span class="phrase"><a name="boost_asio.overview.core.async.implementation_using_windows_overlapped_i_o"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.implementation_using_windows_overlapped_i_o">Implementation 143 Using Windows Overlapped I/O</a> 144 </h6> 145<p> 146 On Windows NT, 2000 and XP, Boost.Asio takes advantage of overlapped I/O 147 to provide an efficient implementation of the Proactor design pattern. 148 This implementation approach corresponds to the Proactor design pattern 149 as follows: 150 </p> 151<p> 152 — Asynchronous Operation Processor 153 </p> 154<div class="blockquote"><blockquote class="blockquote"><p> 155 This is implemented by the operating system. Operations are initiated 156 by calling an overlapped function such as <code class="computeroutput"><span class="identifier">AcceptEx</span></code>. 157 </p></blockquote></div> 158<p> 159 — Completion Event Queue 160 </p> 161<div class="blockquote"><blockquote class="blockquote"><p> 162 This is implemented by the operating system, and is associated with an 163 I/O completion port. There is one I/O completion port for each <code class="computeroutput"><span class="identifier">io_context</span></code> instance. 164 </p></blockquote></div> 165<p> 166 — Asynchronous Event Demultiplexer 167 </p> 168<div class="blockquote"><blockquote class="blockquote"><p> 169 Called by Boost.Asio to dequeue events and their associated completion 170 handlers. 171 </p></blockquote></div> 172<h6> 173<a name="boost_asio.overview.core.async.h3"></a> 174 <span class="phrase"><a name="boost_asio.overview.core.async.advantages"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.advantages">Advantages</a> 175 </h6> 176<p> 177 — Portability. 178 </p> 179<div class="blockquote"><blockquote class="blockquote"><p> 180 Many operating systems offer a native asynchronous I/O API (such as overlapped 181 I/O on <span class="emphasis"><em>Windows</em></span>) as the preferred option for developing 182 high performance network applications. The library may be implemented 183 in terms of native asynchronous I/O. However, if native support is not 184 available, the library may also be implemented using synchronous event 185 demultiplexors that typify the Reactor pattern, such as <span class="emphasis"><em>POSIX</em></span> 186 <code class="computeroutput"><span class="identifier">select</span><span class="special">()</span></code>. 187 </p></blockquote></div> 188<p> 189 — Decoupling threading from concurrency. 190 </p> 191<div class="blockquote"><blockquote class="blockquote"><p> 192 Long-duration operations are performed asynchronously by the implementation 193 on behalf of the application. Consequently applications do not need to 194 spawn many threads in order to increase concurrency. 195 </p></blockquote></div> 196<p> 197 — Performance and scalability. 198 </p> 199<div class="blockquote"><blockquote class="blockquote"><p> 200 Implementation strategies such as thread-per-connection (which a synchronous-only 201 approach would require) can degrade system performance, due to increased 202 context switching, synchronisation and data movement among CPUs. With 203 asynchronous operations it is possible to avoid the cost of context switching 204 by minimising the number of operating system threads — typically a limited 205 resource — and only activating the logical threads of control that have 206 events to process. 207 </p></blockquote></div> 208<p> 209 — Simplified application synchronisation. 210 </p> 211<div class="blockquote"><blockquote class="blockquote"><p> 212 Asynchronous operation completion handlers can be written as though they 213 exist in a single-threaded environment, and so application logic can 214 be developed with little or no concern for synchronisation issues. 215 </p></blockquote></div> 216<p> 217 — Function composition. 218 </p> 219<div class="blockquote"><blockquote class="blockquote"><p> 220 Function composition refers to the implementation of functions to provide 221 a higher-level operation, such as sending a message in a particular format. 222 Each function is implemented in terms of multiple calls to lower-level 223 read or write operations. 224 </p></blockquote></div> 225<div class="blockquote"><blockquote class="blockquote"><p> 226 For example, consider a protocol where each message consists of a fixed-length 227 header followed by a variable length body, where the length of the body 228 is specified in the header. A hypothetical read_message operation could 229 be implemented using two lower-level reads, the first to receive the 230 header and, once the length is known, the second to receive the body. 231 </p></blockquote></div> 232<div class="blockquote"><blockquote class="blockquote"><p> 233 To compose functions in an asynchronous model, asynchronous operations 234 can be chained together. That is, a completion handler for one operation 235 can initiate the next. Starting the first call in the chain can be encapsulated 236 so that the caller need not be aware that the higher-level operation 237 is implemented as a chain of asynchronous operations. 238 </p></blockquote></div> 239<div class="blockquote"><blockquote class="blockquote"><p> 240 The ability to compose new operations in this way simplifies the development 241 of higher levels of abstraction above a networking library, such as functions 242 to support a specific protocol. 243 </p></blockquote></div> 244<h6> 245<a name="boost_asio.overview.core.async.h4"></a> 246 <span class="phrase"><a name="boost_asio.overview.core.async.disadvantages"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.disadvantages">Disadvantages</a> 247 </h6> 248<p> 249 — Program complexity. 250 </p> 251<div class="blockquote"><blockquote class="blockquote"><p> 252 It is more difficult to develop applications using asynchronous mechanisms 253 due to the separation in time and space between operation initiation 254 and completion. Applications may also be harder to debug due to the inverted 255 flow of control. 256 </p></blockquote></div> 257<p> 258 — Memory usage. 259 </p> 260<div class="blockquote"><blockquote class="blockquote"><p> 261 Buffer space must be committed for the duration of a read or write operation, 262 which may continue indefinitely, and a separate buffer is required for 263 each concurrent operation. The Reactor pattern, on the other hand, does 264 not require buffer space until a socket is ready for reading or writing. 265 </p></blockquote></div> 266<h6> 267<a name="boost_asio.overview.core.async.h5"></a> 268 <span class="phrase"><a name="boost_asio.overview.core.async.references"></a></span><a class="link" href="async.html#boost_asio.overview.core.async.references">References</a> 269 </h6> 270<p> 271 [POSA2] D. Schmidt et al, <span class="emphasis"><em>Pattern Oriented Software Architecture, 272 Volume 2</em></span>. Wiley, 2000. 273 </p> 274</div> 275<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> 276<td align="left"></td> 277<td align="right"><div class="copyright-footer">Copyright © 2003-2020 Christopher M. 278 Kohlhoff<p> 279 Distributed under the Boost Software License, Version 1.0. (See accompanying 280 file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) 281 </p> 282</div></td> 283</tr></table> 284<hr> 285<div class="spirit-nav"> 286<a accesskey="p" href="basics.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../core.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../../boost_asio.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="threads.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> 287</div> 288</body> 289</html> 290
