<html><head>
<style>
body { font-family: "Book Antiqua", "Times New Roman", "Times", serif; padding: 2em; }
.programlisting, .computeroutput, .literal { font-family: "Consolas", monospace; font-size: 90%; }
blockquote pre.programlisting { margin-left: 1em; padding-left: 1em; }
div.table { text-align: center; }
.sidebar { background-color: #e0e0e0; font-style: italic; }
p { text-align: justify; }
p.tablecaption { font-weight: bold; text-align: center; }
p.title { font-weight: bold; text-align: center; }
div.section { position: relative; }
span.xrefid { position: absolute; right: 0em; top: 0em; }
table { margin: auto; border: 1px solid gray; border-collapse: collapse; }
th { border: 1px solid gray; padding: 0.5em; }
td { border: 1px solid gray; padding: 0.5em; }
h1, h2, h3, h4, h5, div.titlepage { page-break-after: avoid; }
dl { margin-top: 0px; margin-bottom: 0px; }
</style>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"><title>Some notes on executors and the Networking Library Proposal</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<pre>Doc. no:  N4482 
Date:     2015-04-13
Reply-To: Christopher Kohlhoff &lt;chris@kohlhoff.com&gt;
</pre>
<div class="chapter" title="Some notes on executors and the Networking Library Proposal"><div class="titlepage"><div><div><h2 class="title"><a name="executor_notes"></a>Some notes on executors and the Networking Library Proposal</h2></div></div></div><div class="section" title="1.&#160;Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="executor_notes.introduction"></a>1.&#160;Introduction</h2></div></div></div><p>
      This document is intended to provide some input to further discussion of executors
      by:
    </p><p>
      &#8212; attempting to relate executor requirements, as defined in N4478 <span class="emphasis"><em>Networking
      Library Proposal</em></span>, to the terminology described in N4231 <span class="emphasis"><em>Terms
      and definitions related to threads</em></span> and N4156 <span class="emphasis"><em>Light-Weight
      Execution Agents</em></span>;
    </p><p>
      &#8212; capturing some aspects of the discussion related to executors from the February
      2015 review of the Networking Library Proposal in Cologne; and
    </p><p>
      &#8212; exploring some of the related prior art.
    </p></div><div class="section" title="2.&#160;Executors and progress guarantees"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="executor_notes.executors_and_progress_guarantees"></a>2.&#160;Executors and progress guarantees</h2></div></div></div><p>
      At its most general, one can imagine an executor as something that, when given
      an arbitrary sequence of instructions, runs them as a thread of execution.
      In these terms, there are no particular requirements as to whether an executor
      gives a concurrent, parallel, or weakly parallel progress guarantee.
    </p><p>
      However, the executor model utilised in the Networking Library Proposal traffics
      only in arbitrary &#8220;normal&#8221; function objects executed on the abstract machine.
      A &#8220;normal&#8221; function object will eventually be allowed to execute all steps
      in its thread of execution, but only after it has executed its first step.
      That is, this executor model provides a parallel progress guarantee.
    </p><p>
      Therefore, let us define the executor requirements of the Networking Library
      Proposal as <span class="emphasis"><em>parallel function object executor</em></span> requirements.
    </p><div class="section" title="2.1.&#160;Implementing weaker progress guarantees"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.implementing_weaker_progress_guarantees"></a>2.1.&#160;Implementing weaker progress guarantees</h3></div></div></div><p>
        Of course, we can still use these executors to implement other abstractions
        that do provide no more than a weakly parallel progress guarantee.
      </p><p>
        For instance, we can implement a scheduler for resumable functions on top
        of these executors. A given resumable function can have an associated executor,
        and the work to &#8220;resume&#8221; the resumable function is performed by an implementation-detail
        function object running on that executor. Even though that function object
        is executed with the stronger parallel guarantee, the entire resumable function
        can assume only weakly parallel progress.
      </p></div><div class="section" title="2.2.&#160;Requirements for stronger progress guarantees?"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.requirements_for_stronger_progress_guarantees_"></a>2.2.&#160;Requirements for stronger progress guarantees?</h3></div></div></div><p>
        A library or program is allowed to implement the parallel function object
        executor requirements such that they provide a concurrent progress guarantee.
        One possible example is a <code class="computeroutput"><span class="identifier">new_thread_executor</span></code>
        where every call to <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code>, <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> or <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code> creates a new <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">thread</span></code>.
      </p><p>
        However, the asynchronous operations framework used by the Networking Library
        Proposal does not require a concurrent progress guarantee &#8212; the parallel guarantee
        suffices for all uses. It is also worth noting that implied executor requirements
        of the prior art surveyed below do not require the concurrent guarantee.
      </p><p>
        Yet, as N4156 suggests, there are times when a concurrent guarantee is required,
        and it would be beneficial to be able to detect the ability of an executor
        to meet this guarantee at compile time.
      </p><p>
        Therefore, it may be desirable to define new <span class="emphasis"><em>concurrent function
        object executor</em></span> type requirements. These requirements may be a
        refinement of the parallel function object requirements, or they may be independent.
        As a straw man proposal, consider use of the function name <code class="computeroutput"><span class="identifier">spawn</span><span class="special">()</span></code>
        to mean launch a function object with a concurrent progress guarantee. An
        executor may provide this member function if it is able to meet this guarantee.
      </p><p>
        These hypothetical <span class="emphasis"><em>concurrent function object executor</em></span>
        requirements are out-of-scope for a Networking Library Proposal. Were Networking
        Library executors to impose such a requirement, it would introduce a burden
        on all implementations of the executor type requirements. Furthermore, for
        some executor types the concurrent progress requirements are impossible to
        implement (such as bounded thread pools, and strands or serial executors).
      </p></div></div><div class="section" title="3.&#160;Dispatch, Post and Defer"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="executor_notes.dispatch__post_and_defer"></a>3.&#160;Dispatch, Post and Defer</h2></div></div></div><div class="section" title="3.1.&#160;Dispatch vs Post"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.dispatch_vs_post"></a>3.1.&#160;Dispatch vs Post</h3></div></div></div><p>
        The Networking Library Proposal executor requirements for <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code> say:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>The executor may invoke <code class="computeroutput"><span class="identifier">f1</span></code>
          prior to returning from <code class="computeroutput"><span class="identifier">dispatch</span></code>.</em></span>
        </p></blockquote></div><p>
        This requirement should be redefined in terms of forward progress. For example,
        a better definition may be to say that <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code> is permitted to block the forward progress
        of the caller until <code class="computeroutput"><span class="identifier">f1</span><span class="special">()</span></code>
        finishes execution.
      </p><p>
        The executor requirements for <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> (and, in a similar fashion, <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code>)
        say:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>The executor shall not invoke <code class="computeroutput"><span class="identifier">f1</span></code>
          in the current thread of execution prior to returning from <code class="computeroutput"><span class="identifier">post</span></code>.</em></span>
        </p></blockquote></div><p>
        When considered in terms of forward progress this may be an over-specification.
        A possible redefinition of these requirements may be to say that <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>
        and <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code>
        are not permitted to block the forward progress of the caller pending completion
        of <code class="computeroutput"><span class="identifier">f1</span><span class="special">()</span></code>.
      </p><p>
        When <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>
        is defined in this way, it means that in certain very limited cases an implementation
        of <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>
        may invoke <code class="computeroutput"><span class="identifier">f1</span></code> in the calling
        thread. For example, the type of the function object <code class="computeroutput"><span class="identifier">f1</span></code>
        is "known" to an executor and is "known" to not block.
      </p><div class="section" title="3.1.1.&#160;Just a hint?"><div class="titlepage"><div><div><h4 class="title"><a name="executor_notes.just_a_hint_"></a>3.1.1.&#160;Just a hint?</h4></div></div></div><p>
          Is the choice between <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code> and <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> better presented as a hint to an executor?
        </p><p>
          <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code>
          is provided as a tool to minimise the latency and overhead of <code class="computeroutput"><span class="identifier">f1</span></code>'s execution, provided doing so does
          not violate the rules of the executor. The widespread existence of <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code>
          in the prior art attests to its utility.
        </p><p>
          However, a consequence of <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code>'s specification is that its use can introduce
          deadlock. This occurs when the caller holds a mutex and <code class="computeroutput"><span class="identifier">f1</span></code>
          attempts to acquire the same mutex. Thus the choice between <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code>
          and <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>
          impacts program correctness. A hint, which by definition need not be respected,
          is an inappropriate way for the caller to express its intention.
        </p></div></div><div class="section" title="3.2.&#160;Post vs Defer"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.post_vs_defer"></a>3.2.&#160;Post vs Defer</h3></div></div></div><p>
        Where the distinction between <code class="computeroutput"><span class="identifier">dispatch</span><span class="special">()</span></code> and <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>/<code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code> is related to the forward progress of the
        caller, the distinction between <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> and <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code> relates to the forward progress of <code class="computeroutput"><span class="identifier">f1</span></code>. The executor requirements say:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em><code class="computeroutput"><span class="identifier">defer</span></code> is used
          to convey the intention of the caller that the submitted function is a
          continuation of the current call context. The executor may use this information
          to optimize or otherwise adjust the way in which <code class="computeroutput"><span class="identifier">f</span></code>
          is invoked.</em></span>
        </p></blockquote></div><p>
        A better way to define this may be to say that the use of <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> means that we prefer that the caller <span class="emphasis"><em>does
        not</em></span> block the first step of <code class="computeroutput"><span class="identifier">f1</span></code>'s
        progress, whereas <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code>
        means that we prefer that the caller <span class="emphasis"><em>does</em></span> block the
        first step of <code class="computeroutput"><span class="identifier">f1</span></code>.
      </p><div class="section" title="3.2.1.&#160;Just a hint?"><div class="titlepage"><div><div><h4 class="title"><a name="executor_notes.just_a_hint0"></a>3.2.1.&#160;Just a hint?</h4></div></div></div><p>
          As the difference between <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> and <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code> uses the word "prefer", there
          is a case to be made that this is just a hint to the executor.
        </p><p>
          It may be more than a hint in circumstances where the caller knows something
          about the concrete executor being used. For example, on a specific bounded
          thread pool implementation, a call to <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code> will allow <code class="computeroutput"><span class="identifier">f1</span></code>
          to exploit the available concurrency in the pool even if the caller continues
          to execute. (Although, even if a hint is used to distinguish between <code class="computeroutput"><span class="identifier">post</span><span class="special">()</span></code>
          and <code class="computeroutput"><span class="identifier">defer</span><span class="special">()</span></code>,
          this may be addressed by simply specifying that the concrete executor will
          obey the hint in a certain way.)
        </p></div></div></div><div class="section" title="4.&#160;Related prior art"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="executor_notes.related_prior_art"></a>4.&#160;Related prior art</h2></div></div></div><p>
      In surveying the prior art, we will:
    </p><p>
      &#8212; Identify whether it provides an equivalent to <code class="computeroutput"><span class="identifier">dispatch</span></code>.
    </p><p>
      &#8212; Identify whether it provides an equivalent to <code class="computeroutput"><span class="identifier">post</span></code>.
    </p><p>
      &#8212; Identify whether it provides facilities for counting outstanding work, i.e.
      the equivalent of the <code class="computeroutput"><span class="identifier">on_work_started</span></code>
      and <code class="computeroutput"><span class="identifier">on_work_finished</span></code> functions.
    </p><p>
      The following table summarises the findings. Where a facility is provided it
      is marked "y", otherwise "n'. In some cases, the prior art provides
      a variant of <code class="computeroutput"><span class="identifier">dispatch</span></code> where
      it's not just that it "may" block the caller, but that it always
      blocks the caller. These are marked "y (v)".
    </p><div class="informaltable"><table class="table"><colgroup><col><col><col><col></colgroup><thead><tr><th>
              <p>
                library
              </p>
            </th><th>
              <p>
                dispatch
              </p>
            </th><th>
              <p>
                post
              </p>
            </th><th>
              <p>
                work counting
              </p>
            </th></tr></thead><tbody><tr><td>
              <p>
                Boost.Asio
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                y
              </p>
            </td></tr><tr><td>
              <p>
                Java <code class="computeroutput"><span class="identifier">Executor</span></code>
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                n
              </p>
            </td><td>
              <p>
                n
              </p>
            </td></tr><tr><td>
              <p>
                Grand Central Dispatch queues
              </p>
            </td><td>
              <p>
                y (v)
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                n
              </p>
            </td></tr><tr><td>
              <p>
                .NET <code class="computeroutput"><span class="identifier">SynchronizationContext</span></code>
              </p>
            </td><td>
              <p>
                y (v)
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                y
              </p>
            </td></tr><tr><td>
              <p>
                .NET Reactive Extensions <code class="computeroutput"><span class="identifier">Scheduler</span></code>
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                n
              </p>
            </td><td>
              <p>
                n
              </p>
            </td></tr><tr><td>
              <p>
                Thread Building Blocks <code class="computeroutput"><span class="identifier">task_arena</span></code>
              </p>
            </td><td>
              <p>
                y (v)
              </p>
            </td><td>
              <p>
                y
              </p>
            </td><td>
              <p>
                n
              </p>
            </td></tr></tbody></table></div><div class="section" title="4.1.&#160;Boost.Asio"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.boost_asio"></a>4.1.&#160;Boost.Asio</h3></div></div></div><p>
        Although the Networking Library Proposal is based on Boost.Asio, the executors
        facility is a relatively new addition to the library in order to enable move-only
        completion handlers. In this section we will discuss the original realisation
        of executor facilities in the library.
      </p><p>
        The Boost.Asio <code class="computeroutput"><span class="identifier">io_service</span></code>
        class is an executor for function objects that provides a parallel progress
        guarantee.
      </p><p>
        The <code class="computeroutput"><span class="identifier">io_service</span><span class="special">::</span><span class="identifier">dispatch</span><span class="special">()</span></code>
        and <code class="computeroutput"><span class="identifier">io_service</span><span class="special">::</span><span class="identifier">post</span><span class="special">()</span></code>
        functions provide the <code class="computeroutput"><span class="identifier">dispatch</span></code>
        and <code class="computeroutput"><span class="identifier">post</span></code> semantics respectively.
      </p><p>
        Work counting is performed via the <code class="computeroutput"><span class="identifier">io_service</span><span class="special">::</span><span class="identifier">work</span></code>
        class. Objects of this type automatically count work as they are constructed
        and destroyed.
      </p></div><div class="section" title="4.2.&#160;Java Executor"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.java_executor"></a>4.2.&#160;Java Executor</h3></div></div></div><p>
        <span class="emphasis"><em>(<a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executor.html" target="_top">http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executor.html</a>)</em></span>
      </p><p>
        The Java <code class="computeroutput"><span class="identifier">Executor</span></code> interface
        provides only a single method 'execute'. This method has <code class="computeroutput"><span class="identifier">dispatch</span></code>
        semantics:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>the Executor interface does not strictly require that execution
          be asynchronous. In the simplest case, an executor can run the submitted
          task immediately in the caller's thread.</em></span>
        </p></blockquote></div></div><div class="section" title="4.3.&#160;Grand Central Dispatch queues"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.grand_central_dispatch_queues"></a>4.3.&#160;Grand Central Dispatch queues</h3></div></div></div><p>
        <span class="emphasis"><em>(<a href="https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html" target="_top">https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html</a>)</em></span>
      </p><p>
        Grand Central Dispatch provides dispatch queues, which let you execute arbtitrary
        blocks of code either asynchronously or synchronously with respect to the
        caller. Dispatch queues may be "serial" or "concurrent".
      </p><p>
        The <code class="computeroutput"><span class="identifier">dispatch_sync</span></code> function
        provides <code class="computeroutput"><span class="identifier">dispatch</span></code> semantics.
        However, <code class="computeroutput"><span class="identifier">dispatch_sync</span></code> always
        blocks the caller:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>Submits a block object for execution on a dispatch queue and
          waits until that block completes. ... As an optimization, this function
          invokes the block on the current thread when possible.</em></span>
        </p></blockquote></div><p>
        The <code class="computeroutput"><span class="identifier">dispatch_async</span></code> function
        provides <code class="computeroutput"><span class="identifier">post</span></code> semantics:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>Submits an application-defined function for asynchronous execution
          on a dispatch queue and returns immediately.</em></span>
        </p></blockquote></div></div><div class="section" title="4.4.&#160;.NET SynchronizationContext"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes._net_synchronizationcontext"></a>4.4.&#160;.NET SynchronizationContext</h3></div></div></div><p>
        <span class="emphasis"><em>(<a href="https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx" target="_top">https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx</a>)</em></span>
      </p><p>
        The .NET <code class="computeroutput"><span class="identifier">SynchronizationContext</span></code>
        class is used, amongst other things, to coordinate asynchronous operations
        in a threaded environment.
      </p><p>
        The <code class="computeroutput"><span class="identifier">Send</span></code> function provides
        <code class="computeroutput"><span class="identifier">dispatch</span></code> semantics, however
        it always blocks the caller:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>The Send method starts a synchronous request to send a message.</em></span>
        </p></blockquote></div><p>
        The <code class="computeroutput"><span class="identifier">Post</span></code> function provides
        <code class="computeroutput"><span class="identifier">post</span></code> semantics:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>The Post method starts an asynchronous request to post a message.</em></span>
        </p></blockquote></div><p>
        The <code class="computeroutput"><span class="identifier">OperationStarted</span></code> and
        <code class="computeroutput"><span class="identifier">OperationCompleted</span></code> functions
        provide the work counting facilities.
      </p></div><div class="section" title="4.5.&#160;.NET Reactive Extensions Scheduler"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes._net_reactive_extensions_scheduler"></a>4.5.&#160;.NET Reactive Extensions Scheduler</h3></div></div></div><p>
        <span class="emphasis"><em>(<a href="https://msdn.microsoft.com/en-us/library/system.reactive.concurrency.scheduler(v=vs.103).aspx" target="_top">https://msdn.microsoft.com/en-us/library/system.reactive.concurrency.scheduler(v=vs.103).aspx</a>)</em></span>
      </p><p>
        The <code class="computeroutput"><span class="identifier">Scheduler</span></code> interface provides
        several overloads of a <code class="computeroutput"><span class="identifier">Schedule</span></code>
        function, used to submit actions.
      </p><p>
        The existence of a concrete implementation class <code class="computeroutput"><span class="identifier">ImmediateScheduler</span></code>
        indicates that the <code class="computeroutput"><span class="identifier">Schedule</span></code>
        function provides <code class="computeroutput"><span class="identifier">dispatch</span></code>
        semantics:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>Represents an object that schedules units of work to run immediately
          on the current thread.</em></span>
        </p></blockquote></div></div><div class="section" title="4.6.&#160;Thread Building Blocks task_arena"><div class="titlepage"><div><div><h3 class="title"><a name="executor_notes.thread_building_blocks_task_arena"></a>4.6.&#160;Thread Building Blocks task_arena</h3></div></div></div><p>
        <span class="emphasis"><em>(<a href="https://www.threadingbuildingblocks.org/docs/help/reference/task_scheduler/task_arena_cls.htm" target="_top">https://www.threadingbuildingblocks.org/docs/help/reference/task_scheduler/task_arena_cls.htm</a>)</em></span>
      </p><p>
        A <code class="computeroutput"><span class="identifier">task_arena</span></code> class "represents
        an internal task scheduler object where a number of threads, limited by a
        maximal concurrency level, share and execute tasks".
      </p><p>
        The <code class="computeroutput"><span class="identifier">execute</span></code> function provides
        <code class="computeroutput"><span class="identifier">dispatch</span></code> semantics, however
        it always blocks the caller:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>If possible, the calling thread joins the arena and executes
          the specified functor, then leaves the arena ... If not possible to join,
          the call wraps the functor into a task, enqueues it into the arena, waits
          using an OS kernel synchronization object for a joining opportunity, and
          finishes after the task completion.</em></span>
        </p></blockquote></div><p>
        The <code class="computeroutput"><span class="identifier">enqueue</span></code> function provides
        <code class="computeroutput"><span class="identifier">post</span></code> semantics:
      </p><div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>Enqueues a task into the arena to process specified functor and
          immediately returns.</em></span>
        </p></blockquote></div></div></div></div></body></html>
