The behaviour of std::async() function, when used with std::launch::async, may be trivially emulated as follows:

template <class F, class... Args>
auto async(F&& f, Args&&... args)
{
  return post(
    package(
      std::bind(std::forward<F>(f),
        std::forward<Args>(args)...)));
}

Starting from the inside out, the expression:

std::bind(std::forward<F>(f),
  std::forward<Args>(args)...)

creates a function object that will invoke f with the specified arguments. Next:

package(...)

returns an object that will be lazily converted into a std::packaged_task<>. We could also have used std::packaged_task<> directly, as in:

std::packaged_task<
  std::result_of_t<
    std::decay_t<F>(std::decay_t<Args>...)>>(...)

In this example, the package() function saves on typing by determining the return type of F for us. Finally:

post(...)

submits the function object for execution on another thread, and then returns immediately. When we submit a std::packaged_task<>, post() automatically deduces its return type to be the std::future<> type produced by the task. This future object is then returned from our version of async(). Note that, unlike std::async(), the returned future object's destructor will not block.

In the Active Object design pattern, all operations associated with an object are run in its own private thread.

To implement an active object, we begin by defining a class member that is a thread pool containing a single thread.

class bank_account
{
  int balance_ = 0;
  mutable thread_pool pool_{1};
  // ...
};

We then define each public member function so that it posts its implementation to the thread pool.

class bank_account
{
  // ...
  void deposit(int amount)
  {
    post(pool_,
      package([=]
        {
          balance_ += amount;
        })).get();
  }
  // ...
};

In more detail, to implement an active object operation we begin by defining the body of the function:

[=]
{
  balance_ += amount;
}

which we then wrap in a lazily created std::packaged_task<>:

package(...)

Finally, we submit the packaged task to the pool and wait for it to complete. When we submit a std::packaged_task<>, post() automatically deduces its return type to be the std::future<> type produced by the task. We can use this future to block until the operation is complete.

post(...).get();

An Activatable object is a variant of the Active Object pattern where the object does not have a private thread of its own. Instead, it can borrow one of the calling threads to process operations^[1]. However, like Active Object, it ensures that all member state changes do not occur on more than one thread at a time.

To implement an activatable object, we create a strand on the system executor.

class bank_account
{
  int balance_ = 0;
  mutable strand<system_executor> strand_;
  // ...
};

We then define each public member function so that it dispatches its implementation to the strand.

class bank_account
{
  // ...
  void deposit(int amount)
  {
    dispatch(strand_,
      package([=]
        {
          balance_ += amount;
        })).get();
  }
  // ...
};

Recall that a system_executor object embodies this rule:

while a strand embodies this rule:

Finally, the call to dispatch() means:

Thus, when we combine system_executor, strand and dispatch():

dispatch(strand_, []{ ... });

we are effectively saying: if the strand is not busy, run the function object immediately. If there is no contention on the strand, latency is minimised. If there is contention, the strand still ensures that the function object never runs concurrently with any other function object submitted through the same strand.

The Leader/Followers design pattern is a model where multiple threads take turns to wait on event sources in order to dispatch and process incoming events.

Consider an example where a connection handler is responsible for receiving messages from a client via UDP. The Leader/Followers pattern is implemented using a thread_pool object:

class connection_handler
{
  // ...
private:
  udp_socket socket_;
  thread_pool thread_pool_;
  // ...
};

and involves the sequence of operations below.

void connection_handler::receive_and_dispatch()
{

The leader thread waits for the next message to arrive.

  char buffer[1024];
  std::size_t length = socket_.receive(buffer, sizeof(buffer));

A new message has arrived. The leader thread promotes a follower to become the new leader.

  std::experimental::post(thread_pool_,
      [this]{ receive_and_dispatch(); });

The now former leader processes the message.

  // Process the new message and pass it to the order management bus.
  std::istringstream is(std::string(buffer, length));
  order_management::new_order event;
  if (is >> event)
    order_management_bus_.dispatch_event(event);
}

When the function returns, the former leader automatically returns to the pool as a follower thread.

Asynchronous operations are often chained, and in many cases an object may be associated with two or more chains. For example, an object to manage a connection may contain one chain to do the writing, and another to do the reading:

class connection
{
  tcp::socket socket_;
  mutable_buffers_1 in_buffer_;
  mutable_buffers_1 out_buffer_;

  // ...

  void do_read()
  {
    socket_.async_read_some(in_buffer_,
      [this](error_code ec, size_t n)
      {
        // ... process input data ...
        if (!ec) do_read();
      });
  }

  void do_write()
  {
    // ... generate output data ...
    async_write(socket_, out_buffer_,
      [this](error_code ec, size_t n)
      {
        if (!ec) do_write();
      });
  }
};

When these chains are run on a single-threaded event loop, it is not possible for more than one completion handler to run at any given time. This means that no synchronisation is required to protected shared data. However, if handlers are executed on a thread pool then some form of synchronisation will be required to avoid introducing data races.

The proposed library provides the strand<> template to synchronise handlers. A strand ensures that completion handlers never run concurrently, and explicit synchronisation (such as a mutex) is still not required to protect shared data. To implement this, we use the one strand for all asynchronous operations associated with the object.

class connection
{
  tcp::socket socket_;
  mutable_buffers_1 in_buffer_;
  mutable_buffers_1 out_buffer_;
  strand<io_service::executor_type> strand_;

  // ...

  void do_read()
  {
    socket_.async_read_some(in_buffer_,
      wrap(strand_, [this](error_code ec, size_t n)
        {
          // ... process input data ...
          if (!ec) do_read();
        }));
  }

  void do_write()
  {
    // ... generate output data ...
    async_write(socket_, out_buffer_,
      wrap(strand_, [this](error_code ec, size_t n)
        {
          if (!ec) do_write();
        }));
  }
};

The wrap function is used to associated an executor with an object. In this example, we used wrap to associated the strand with each of the lambdas. The wrap function works with any executor or execution context. For example, here we associate a thread pool with a lamdba:

async_getline(std::cin,
    wrap(pool, [](std::string line)
      {
        std::cout << "Line: " << line << "\n";
      }));

Rather than using the wrap function, the associated executor may be manually specified by providing a nested executor_type typedef and get_executor() member function.

class line_printer
{
public:
  typedef loop_scheduler::executor_type executor_type;

  explicit line_printer(loop_scheduler& s)
    : executor_(s.get_executor())
  {
  }

  executor_type get_executor() const noexcept
  {
    return executor_;
  }

  void operator()(std::string line)
  {
    std::cout << "Line: " << line << "\n";
  }

private:
  loop_scheduler::executor_type executor_;
};

// ...

async_getline(std::cin, line_printer(scheduler));

For this to work correctly, the async_getline asynchronous operation must participate in an executor-aware model. To be executor-aware, an asynchronous operation must:

Our async_getline operation can then be written as follows:

template <class Handler>
void async_getline(std::istream& is, Handler handler)
{

The make_work function automatically obtains the associated executor and creates an executor_work object for it.

  auto work = make_work(handler);

The asynchronous operation itself is posted outside of the associated executor. This is because we want the line reading to be performed asynchronously with respect to the caller.

  post([&is, work, handler=std::move(handler)]() mutable
      {
        std::string line;
        std::getline(is, line);

Once the asynchronous work is complete, we execute the completion handler via its associated executor.

        // Pass the result to the handler, via the associated executor.
        dispatch(work.get_executor(),
            [line=std::move(line), handler=std::move(handler)]() mutable
            {
              handler(std::move(line));
            });
      });
}

When composing asynchronous operations, intermediate operations can simply reuse the associated executor of the final handler.

template <class Handler>
void async_getlines(std::istream& is, std::string init, Handler handler)
{
  // Get the final handler's associated executor.
  auto ex = get_associated_executor(handler);

  // Use the associated executor for each operation in the composition.
  async_getline(is,
      wrap(ex, [&is, lines=std::move(init), handler=std::move(handler)]
        (std::string line) mutable
        {
          if (line.empty())
            handler(lines);
          else
            async_getlines(is, lines + line + "\n", std::move(handler));
        }));
}

This ensures that all intermediate completion handlers are correctly executed according to the caller's executor's rules.

A pipeline is a sequence of two or more long-running functions, known as stages, with each stage passing data to the next via a queue. The initial stage acts as a source of data, the intermediate stages act as filters, and the final stage as a sink.

As an example, let us consider a small framework for implementing pipelines. The function used to construct a pipeline is declared as:

template <class F, class... Tail>
  std::future<void> pipeline(F f, Tail... t);

This function returns a future that can be used to wait until the pipeline is complete. The initial stage of the pipeline must be a function with signature:

void initial(queue_front<T0> out);

The intermediate stages have signature:

void intermediate(queue_back<Tn> in, queue_front<Tn+1> out);

The pipeline's final stage has the signature:

void final(queue_back<TN> in);

By default, we want each stage of a pipeline to have its own thread. The pipeline framework achieves this by calling get_associated_executor with two arguments:

template <class F, class... Tail>
std::future<void> pipeline(F f, Tail... t)
{
  // ...
  auto ex = get_associated_executor(f, thread_executor());
  // ...
}

The thread_executor class is a custom executor type defined for the example. It starts a new thread for every function passed to dispatch, post or defer. If the function object type F already has an associated executor then that executor will be used. The thread_executor is used for types that do not specify an associated executor.

So, when we construct and run a pipeline like this:

void reader(queue_front<std::string> out);
void filter(queue_back<std::string> in, queue_front<std::string> out);
void upper(queue_back<std::string> in, queue_front<std::string> out);
void writer(queue_back<std::string> in);

// ...

thread_pool pool;
auto f = pipeline(reader, filter, wrap(pool, upper), writer);
f.wait();

we are specifying that the the upper stage should run on the thread pool, while reader, filter and writer should use the default behaviour of launching a new thread.

The Actor model is a model for concurrency where objects, known as actors, communicate only by sending and receiving messages. Each actor's state is accessed only by its own internal thread or strand. This means that actors are inherently thread-safe.

To illustrate how executors may be used to facilitate actors, a tiny actor framework is included with the executors reference implementation. This framework is loosely based on the Theron library^[2].

To implement an actor using this framework, we start by deriving a class from actor:

class member : public actor
{
  // ...

When constructing an actor, we specify the executor to be used:

  explicit member(executor e)
    : actor(std::move(e))
  {
    // ...
  }

The polymorphic type executor is used to allow the selection of an actor's executor to be delayed until runtime. All of an actor's message handlers are executed according to that policy. This could be a thread pool executor, but we may equally construct actors with an executor that knows about priorities.

The actor's message handlers are member functions, identified by argument type, and may be arbitrarily registered or deregistered:

  void init_handler(actor_address next, actor_address from)
  {
    // ...
    register_handler(&member::token_handler);
    deregister_handler(&member::init_handler);
  }

Internally, the actor framework uses a per-actor strand to ensure that the member functions are never called concurrently.

To send a message between actors we use either actor::send() or actor::tail_send(). The send() operation is implemented in terms of the actor's executor's post() member function. The tail_send() function is a distinct operation and conveys additional information about the caller's intent which may be used to optimise inter-actor messaging. It is implemented in terms of defer().

  void token_handler(int token, actor_address /*from*/)
  {
    // ...
    tail_send(msg, to);
  }

  // ...
};

Executor objects are lightweight and copyable to allow us to encapsulate all sorts of additional information and behaviour on a fine-grained basis. One use case for this is attaching priorities to function objects or tasks.

We begin by defining our priority scheduler class as an execution context. Internally, this class uses a priority queue to store pending function objects.

class priority_scheduler : public execution_context
{
  // ...

private:

  // ...

  struct item_comp
  {
    bool operator()(
        const std::shared_ptr<item_base>& a,
        const std::shared_ptr<item_base>& b)
    {
      return a->priority_ < b->priority_;
    }
  };

  std::mutex mutex_;
  std::condition_variable condition_;
  std::priority_queue<
    std::shared_ptr<item_base>,
    std::vector<std::shared_ptr<item_base>>,
    item_comp> queue_;
  bool stopped_ = false;
};

The priority_scheduler class provides a nested class executor_type which satisfies the executor type requirements, and a member function get_executor() to obtain an executor object. On construction, an executor_type object captures a reference to the priority scheduler, as well as the specified priority value.

class priority_scheduler : public execution_context
{
public:
  class executor_type
  {
  public:
    executor_type(priority_scheduler& ctx, int pri) noexcept
      : context_(ctx), priority_(pri)
    {
    }

    // ...

  private:
    priority_scheduler& context_;
    int priority_;
  };

  executor_type get_executor(int pri = 0) noexcept
  {
    return executor_type(*this, pri);
  }

  // ...
};

When a function object is submitted, the executor uses its stored priority to insert the function into the correct position in the priority queue:

class priority_scheduler : public execution_context
{
public:
  class executor_type
  {
  public:

    // ...

    template <class Func, class Alloc>
    void post(Func f, const Alloc& a)
    {
      auto p(std::allocate_shared<item<Func>>(a, priority_, std::move(f)));
      std::lock_guard<std::mutex> lock(context_.mutex_);
      context_.queue_.push(p);
      context_.condition_.notify_one();
    }

    // ...
  };

  // ...
};

The priority scheduler's executors can then be used like any other:

priority_scheduler sched;
auto low = sched.get_executor(0);
auto med = sched.get_executor(1);
auto high = sched.get_executor(2);
// ...
dispatch(low, []{ std::cout << "1\n"; });
dispatch(med, []{ std::cout << "2\n"; });
dispatch(high, []{ std::cout << "3\n"; });

As we will see in this proposal, a template-based design does not preclude the inclusion of a runtime polymorphic wrapper. Such a wrapper still allows users to write non-template code for use with executors, and makes it possible to pass executors across a binary interface. On the other hand, it is not possible to undo the performance impact of a type-erased interface.

This claim might be true when passing coarse-grained tasks across threads. However, use cases for executors are not limited to this. As outlined in N4045, composition of asynchronous operations may entail multiple layers of abstraction. The ability to leverage function inlining is a key part of delivering a low abstraction penalty, but the compiler is unable to see through a virtual interface.

By forcing type erasure at the executor interface, an executor implementer is denied the opportunity to choose a more appropriate form of type erasure. For example, an implementer may wish to store pending work items in a linked list. With a template-based approach, the function object and the “next pointer” can be stored in the same object. This is not possible if type erasure has already occurred^[3].

There is a key use case for wanting to execute work items inline: delivering the result of an asynchronous operation, possibly across multiple layers of abstraction. Rather than relying on the executor to “somehow have to know”, we can allow the user to choose. This is the approach taken in this proposal.

Finally, another disadvantage of std::function is that it prevents the use of move-only function objects.

Of course, as N3785 states, the need for a type-erased function object is itself a consequence of the use of inheritance and polymorphism.

N3785 couples timer-based operations to executors via the scheduled_executor base class. This proposal avoids this coupling by distinguishing between the executor as a lightweight policy object, and an execution context where the “implementation complexity” of timers can be housed in a reusable way. Thus, timer operations are independent of executor types, and can be used with any executor.

Unfortunately, N3785 chooses system_clock as that single clock. As the system clock is susceptible to clock changes it may be inappropriate for use cases that require a periodic timer. In those instances, steady_clock is the better choice.

In any case, by decoupling timers from executors, this proposal provides timer operations that are indeed templates, and can work with arbitrary clock types.

Rather than apply a blanket rule, this proposal includes exception handling as part of an executor’s policy. While std::terminate is likely to be the best choice for unhandled exceptions inside a thread pool, users may prefer greater control when using something like loop_executor. For example, the approach taken by Boost.Asio’s io_service and this proposal’s loop_scheduler is to allow exceptions to escape from the “event loop”, where the user can handle them as appropriate.

Since the executor interface is defined by an abstract base class, code that calls the add() function has to assume that the underlying executor may execute the function object inline. As a consequence, extra care must be taken in situations such as:

This proposal instead makes an explicit distinction between operations that can execute inline, and those that cannot. The library user is then able to choose the appropriate operation for their use case.

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class CompletionToken, class Signature, class = void>
        struct handler_type;

      template<class CompletionToken, class Signature>
        using handler_type_t =
          typename handler_type<CompletionToken, Signature>::type;

      template<class Handler> class async_result;

      template<class CompletionToken, class Signature>
        struct async_completion;

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class CompletionToken, class Signature, class = void>
      struct handler_type
      {
        typedef see below type;
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

Template parameter CompletionToken specifies the model used to obtain the result of the asynchronous operation. Template parameter Signature is the call signature (C++ Std, [func.def]) for the handler type invoked on completion of the asynchronous operation.

A program may specialize this trait if the CompletionToken template parameter in the specialization is a user-defined type.

Specializations of handler_type shall define a nested handler type type that satisfies the MoveConstructible requirements, and objects of type type shall be constructible from an lvalue or rvalue of the type specified by the CompletionToken template parameter.

typedef see below type;

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class Handler>
      class async_result
      {
      public:
        typedef void type;

        explicit async_result(Handler&);
        async_result(const async_result&) = delete;
        async_result& operator=(const async_result&) = delete;

        type get();
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

Template argument Handler is a handler type produced by handler_type_t<T, S> for some completion token type T and call signature S.

A program may specialize this template if the Handler template parameter in the specialization is a user-defined type.

Specializations of async_result shall satisfy the Destructible requirements (C++ Std, [destructible]) in addition to the requirements in the table below. In this table, R is a specialization of async_result for the template parameter Handler; r is a modifiable lvalue of type R; and h is a modifiable lvalue of type Handler.

explicit async_result(Handler&);

type get();

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class CompletionToken, class Signature>
      struct async_completion
      {
        typedef handler_type_t<CompletionToken, Signature> handler_type;

        explicit async_completion(remove_reference_t<CompletionToken>& t);
        async_completion(const async_completion&) = delete;
        async_completion& operator=(const async_completion&) = delete;

        see below handler;
        async_result<handler_type> result;
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

Template parameter CompletionToken specifies the model used to obtain the result of the asynchronous operation. Template parameter Signature is the call signature (C++ Std, [func.def]) for the handler type invoked on completion of the asynchronous operation.

explicit async_completion(remove_reference_t<CompletionToken>& t);

see below handler;

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class T, class Alloc = allocator<void>>
        struct associated_allocator;

      template<class T, class Alloc = allocator<void>>
        using associated_allocator_t = typename associated_allocator<T, Alloc>::type;

      // get_associated_allocator:

      template<class T>
        associated_allocator_t<T> get_associated_allocator(const T& t);
      template<class T, class Alloc>
        associated_allocator_t<T, Alloc>
          get_associated_allocator(const T& t, const Alloc& a);

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class T, class Alloc = allocator<void>>
      struct associated_allocator
      {
        typedef see below type;

        static type get(const T& t, const Alloc& a = Alloc()) noexcept;
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

A program may specialize this traits type if the T template parameter in the specialization is a user-defined type. The template parameter Alloc shall be a type meeting Allocator requirements (C++ Std, [allocator.requirements]).

Specializations of associated_allocator shall satisfy the requirements in the table below. In this table, X is a specialization of associated_allocator for the template parameter T; t is a const reference to an object of type T; and a is an object of type Alloc.

typedef see below type;

type get(const T& t, const Alloc& a = Alloc()) noexcept;

template<class T>
  associated_allocator_t<T> get_associated_allocator(const T& t);

template<class T, class Alloc>
  associated_allocator_t<T, Alloc>
    get_associated_allocator(const T& t, const Alloc& a);

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      enum class fork_event {
        prepare,
        parent,
        child
      };

      class execution_context;

      class service_already_exists;

      template<class Service> Service& use_service(execution_context& ctx);
      template<class Service, class... Args> Service&
        make_service(execution_context& ctx, Args&&... args);
      template<class Service> bool has_service(execution_context& ctx) noexcept;

      template<class T> struct is_executor : false_type {};

      struct executor_arg_t { };
      constexpr executor_arg_t executor_arg = executor_arg_t();

      template<class T, class Executor> struct uses_executor;

      template<class T, class Executor = system_executor>
        struct associated_executor;

      template<class T, class Executor = system_executor>
        using associated_executor_t = typename associated_executor<T, Executor>::type;

      // get_associated_executor:

      template<class T>
        associated_executor_t<T> get_associated_executor(const T& t);
      template<class T, class Executor>
        associated_executor_t<T, Executor>
          get_associated_executor(const T& t, const Executor& ex);
      template<class T, class ExecutionContext>
        associated_executor_t<T, typename ExecutionContext::executor_type>
          get_associated_executor(const T& t, ExecutionContext& ctx);

      template<class T, class Executor> struct executor_wrapper;

      template<class T, class Executor, class Signature>
        struct handler_type<executor_wrapper<T, Executor>, Signature>;

      template<class T, class Executor>
        class async_result<executor_wrapper<T, Executor>>;

      template<class T, class Executor, class Allocator>
        struct associated_allocator<executor_wrapper<T, Executor>, Allocator>;

      template<class T, class Executor, class Executor1>
        struct associated_executor<executor_wrapper<T, Executor>, Executor1>;

      // wrap:

      template<class Executor, class T>
        executor_wrapper<decay_t<T>, Executor> wrap(const Executor& ex, T&& t);
      template<class ExecutionContext, class T>
        executor_wrapper<decay_t<T>, typename ExecutionContext::executor_type>
          wrap(ExecutionContext& ctx, T&& t);

      template<class T, class Executor> struct executor_work;

      // make_work:

      template<class Executor>
        executor_work<Executor>
          make_work(const Executor& ex);
      template<class ExecutionContext>
        executor_work<typename ExecutionContext::executor_type>
          make_work(ExecutionContext& ctx);
      template<class T>
        executor_work<associated_executor_t<T>>
          make_work(const T& t);
      template<class T, class Executor>
        executor_work<associated_executor_t<T, Executor>>
          make_work(const T& t, const Executor& ex);
      template<class T, class ExecutionContext>
        executor_work<associated_executor_t<T, typename ExecutionContext::executor_type>>
          make_work(const T& t, ExecutionContext& ctx);

      class system_executor;

      bool operator==(const system_executor&, const system_executor&);
      bool operator!=(const system_executor&, const system_executor&);

      template<> struct is_executor<system_executor> : true_type {};

      class bad_executor;

      class executor;

      template <> struct is_executor<executor> : true_type {};

      bool operator==(const executor& a, const executor& b) noexcept;
      bool operator==(const executor& e, nullptr_t) noexcept;
      bool operator==(nullptr_t, const executor& e) noexcept;
      bool operator!=(const executor& a, const executor& b) noexcept;
      bool operator!=(const executor& e, nullptr_t) noexcept;
      bool operator!=(nullptr_t, const executor& e) noexcept;

      // dispatch:

      template<class CompletionToken>
        auto dispatch(CompletionToken&& token);
      template<class Executor, class CompletionToken>
        auto dispatch(const Executor& ex, CompletionToken&& token);
      template<class ExecutionContext, class CompletionToken>
        auto dispatch(ExecutionContext& ctx, CompletionToken&& token);

      // post:

      template<class CompletionToken>
        auto post(CompletionToken&& token);
      template<class Executor, class CompletionToken>
        auto post(const Executor& ex, CompletionToken&& token);
      template<class ExecutionContext, class CompletionToken>
        auto post(ExecutionContext& ctx, CompletionToken&& token);

      // defer:

      template<class CompletionToken>
        auto defer(CompletionToken&& token);
      template<class Executor, class CompletionToken>
        auto defer(const Executor& ex, CompletionToken&& token);
      template<class ExecutionContext, class CompletionToken>
        auto defer(ExecutionContext& ctx, CompletionToken&& token);

    } // inline namespace concurrency_v1
  } // namespace experimental

  template<class Alloc>
    struct uses_allocator<std::experimental::concurrency_v1::executor, Alloc>
      : true_type {};

} // namespace std

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      class execution_context
      {
      public:
        class service;

        // construct / copy / destroy:

        execution_context();
        execution_context(const execution_context&) = delete;
        execution_context& operator=(const execution_context&) = delete;
        virtual ~execution_context();

        // execution context operations:

        void notify_fork(fork_event e);

      protected:

        // execution context protected operations:

        void shutdown_context();
        void destroy_context();
      };

      // service access:
      template<class Service> Service& use_service(execution_context& ctx);
      template<class Service, class... Args> Service&
        make_service(execution_context& ctx, Args&&... args);
      template<class Service> bool has_service(execution_context& ctx) noexcept;
      class service_already_exists : public logic_error { ... };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

Class execution_context implements an extensible, type-safe, polymorphic set of services, indexed by service type.

Access to the services of an execution_context is via three function templates, use_service<>, make_service<> and has_service<>.

In a call to use_service<Service>(), the type argument chooses a service, making available all members of the named type. If the service is not present in an execution_context, an object of type Service is created and added to the execution_context. A C++ program can check if an execution_context implements a particular service with the function template has_service<Service>().

Service objects may be explicitly added to an execution_context using the function template make_service<Service>(). If the service is already present, the service_already_exists exception is thrown.

Once a service reference is obtained from an execution_context object by calling use_service<>, that reference remains usable until a call to destroy_context().

execution_context();

~execution_context();

void notify_fork(fork_event e);

void shutdown_context();

void destroy_context();

template<class Service> Service& use_service(execution_context& ctx);

template<class Service, class... Args> Service&
  make_service(execution_context& ctx, Args&&... args);

template<class Service> bool has_service(execution_context& ctx) noexcept;

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      class execution_context::service
      {
      protected:
        // construct / copy / destroy:

        service(execution_context& owner);
        service(const service&) = delete;
        service& operator=(const service&) = delete;
        virtual ~service();

        // service observers:

        execution_context& context() noexcept;

      private:
        friend class execution_context; // exposition only

        // service operations:

        virtual void shutdown_service() = 0;
        virtual void notify_fork(fork_event e);

        execution_context& context_; // exposition only
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

service(execution_context& owner);

execution_context& context() noexcept;

void notify_fork(fork_event e);

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class T> struct is_executor : false_type {};

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

is_executor can be used to detect executor types satisfying the Executor type requirements.

Instantiations of the is_executor template shall meet the UnaryTypeTrait requirements (C++ Std, [meta.rqmts]). A program may specialize this template for a user-defined type T to have a BaseCharacteristic of integral_constant<int, N> with N > 0 to indicate that T should be treated as an executor type.

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      struct executor_arg_t { };
      constexpr executor_arg_t executor_arg = executor_arg_t();

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

The executor_arg_t struct is an empty structure type used as a unique type to disambiguate constructor and function overloading. Specifically, types may have constructors with executor_arg_t as the first argument, immediately followed by an argument of a type that satisfies the Executor requirements.

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class T, class Executor = system_executor>
      struct associated_executor
      {
        typedef see below type;

        static type get(const T& t, const Executor& e = Executor()) noexcept;
      };

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std

A program may specialize this traits type if the T template parameter in the specialization is a user-defined type. The template parameter Executor shall be a type meeting Executor requirements.

Specializations of associated_executor shall satisfy the requirements in the table below. In this table, X is a specialization of associated_executor for the template parameter T; t is a const reference to an object of type T; and e is an object of type Executor.

typedef see below type;

type get(const T& t, const Executor& e = Executor()) noexcept;

template<class T>
  associated_executor_t<T> get_associated_executor(const T& t);

template<class T, class Executor>
  associated_executor_t<T, Executor>
    get_associated_executor(const T& t, const Executor& ex);

template<class T, class ExecutionContext>
  associated_executor_t<T, typename ExecutionContext::executor_type>
    get_associated_executor(const T& t, ExecutionContext& ctx);

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {

      template<class T, class Executor>
      class executor_wrapper
      {
      public:
        // types:

        typedef T wrapped_type;
        typedef Executor executor_type;
        typedef see below result_type;          // not always defined
        typedef see below argument_type;        // not always defined
        typedef see below first_argument_type;  // not always defined
        typedef see below second_argument_type; // not always defined

        // construct / copy / destroy:

        executor_wrapper(T t, const Executor& ex);
        executor_wrapper(const executor_wrapper& other) = default;
        executor_wrapper(executor_wrapper&& other) = default;
        template<class U, class OtherExecutor>
          executor_wrapper(const executor_wrapper<U, OtherExecutor>& other);
        template<class U, class OtherExecutor>
          executor_wrapper(executor_wrapper<U, OtherExecutor>&& other);
        template<class U, class OtherExecutor>
          executor_wrapper(executor_arg_t, const Executor& ex,
            const executor_wrapper<U, OtherExecutor>& other);
        template<class U, class OtherExecutor>
          executor_wrapper(executor_arg_t, const Executor& ex,
            executor_wrapper<U, OtherExecutor>&& other);

        ~executor_wrapper();

        // executor wrapper access:

        T& unwrap() noexcept;
        const T& unwrap() const noexcept;
        executor_type get_executor() const noexcept;

        // executor wrapper invocation:

        template<class... Args>
          result_of_t<cv T&(Args&&...)> operator()(Args&&... args) cv;

      private:
        Executor ex_; // exposition only
        T wrapped_; // exposition only
      };

      template<class T, class Executor, class Signature>
      struct handler_type<executor_wrapper<T, Executor>, Signature>
      {
        typedef executor_wrapper<handler_type_t<T, Signature>, Executor> type;
      };

      template<class T, class Executor>
        class async_result<executor_wrapper<T, Executor>>;

      template<class T, class Executor, class Alloc>
        struct associated_allocator<executor_wrapper<T, Executor>, Alloc>;

      template<class T, class Executor, class Executor1>
        struct associated_executor<executor_wrapper<T, Executor>, Executor1>;

    } // inline namespace concurrency_v1
  } // namespace experimental
} // namespace std