Namespaces
Variants
Views
Actions

Difference between revisions of "cpp/execution"

From cppreference.com
< cpp
(~ rearrange)
m (~ added more items (core ops + queries) [partially])
Line 58: Line 58:
 
{{dsc end}}
 
{{dsc end}}
  
===Execution contexts===
+
===Utility components===
 +
====Execution contexts====
 
{{dsc begin}}
 
{{dsc begin}}
 
{{dsc header|execution}}
 
{{dsc header|execution}}
Line 65: Line 66:
 
{{dsc end}}
 
{{dsc end}}
  
===Completion functions===
+
====Execution domains====
 +
{{todo|WIP update to current standard in progress}}
 +
 
 +
====Forward progress guarantee====
 +
{{dsc begin}}
 +
{{dsc header|execution}}
 +
{{dsc namespace|std::execution}}
 +
{{dsc inc|cpp/execution/dsc forward_progress_guarantee}}
 +
{{dsc end}}
 +
 
 +
====Environments====
 +
{{todo|WIP update to current standard in progress}}
 +
 
 +
====Queries====
 +
{{dsc begin}}
 +
{{dsc header|execution}}
 +
{{dsc inc|cpp/execution/dsc forwarding_query}}
 +
{{dsc inc|cpp/execution/dsc get_allocator}}
 +
{{dsc inc|cpp/execution/dsc get_stop_token}}
 +
{{dsc inc|cpp/execution/dsc get_domain}}
 +
{{dsc inc|cpp/execution/dsc get_scheduler}}
 +
{{dsc inc|cpp/execution/dsc get_delegation_scheduler}}
 +
{{dsc inc|cpp/execution/dsc get_completion_scheduler}}
 +
{{dsc inc|cpp/execution/dsc get_forward_progress_guarantee}}
 +
{{dsc end}}
 +
 
 +
====Completion signatures====
 +
{{todo|WIP update to current standard in progress}}
 +
 
 +
====Coroutine utility====
 +
{{todo|WIP update to current standard in progress}}
 +
 
 +
===Core operations===
 +
====Operation state====
 +
{{dsc begin}}
 +
{{dsc header|execution}}
 +
{{dsc namespace|std::execution}}
 +
{{dsc inc|cpp/execution/dsc connect}}
 +
{{dsc inc|cpp/execution/dsc start}}
 +
{{dsc end}}
 +
 
 +
====Completion functions====
 
These functions are called by senders to announce the completion of the work to their receivers.
 
These functions are called by senders to announce the completion of the work to their receivers.
 
{{dsc begin}}
 
{{dsc begin}}

Revision as of 05:37, 13 October 2024

 
 
 

The Execution library provides a framework for managing asynchronous execution on generic execution resources.

The library aims to provide vocabulary types for asynchronous operations and to allow the construction of task execution graphs in a simple, composable way.

Contents

Library-wide definitions

  • Sender: A description of asynchronous work to be sent for execution. Produces an operation state (below).
  • Senders asynchronously “send” their results to listeners called “receivers” (below).
  • Senders can be composed into task graphs using generic algorithms.
  • Sender factories and adaptors are generic algorithms that capture common async patterns in objects satisfying the sender concept.
  • Receiver: A generalized callback that consumes or “receives” the asynchronous results produced by a sender.
  • Receivers have three different “channels” through which a sender may propagate results: success, failure, and canceled, so-named “value”, “error”, and “stopped”.
  • Receivers provide an extensible execution environment: a set of key/value pairs that the consumer can use to parameterize the asynchronous operation.
  • Operation State: An object that contains the state needed by the asynchronous operation.
  • A sender and receiver are connected when passed to the std::execution::connect function.
  • The result of connecting a sender and a receiver is an operation state.
  • Work is not enqueued for execution until “start” is called on an operation state.
  • Once started, the operation state’s lifetime cannot end before the async operation is complete, and its address must be stable.
  • Scheduler: A lightweight handle to an execution context.
  • An execution context is a source of asynchronous execution such as a thread pool or a GPU stream.
  • A scheduler is a factory for a sender that completes its receiver from a thread of execution owned by the execution context.

Library utilities

Concepts

Schedulers

Defined in header <execution>
Defined in namespace std::execution
specifies that a type is a scheduler
(concept) [edit]

Senders

Defined in header <execution>
Defined in namespace std::execution
specifies that a type is a sender
(concept) [edit]
specifies a sender that can create asynchronous operations for given associated environment type
(concept) [edit]
specifies a sender that can connect with a specific receiver type
(concept) [edit]

Receivers

Defined in header <execution>
Defined in namespace std::execution
specifies that a type is a receiver
(concept) [edit]
specifies that a type is a receiver for given completion signatures
(concept) [edit]

Operation states

Defined in header <execution>
Defined in namespace std::execution
specifies that a type is an operation state
(concept) [edit]

Utility components

Execution contexts

Defined in header <execution>
Defined in namespace std::execution
execution resource holding a thread-safe MPSC task queue and a manually-driven event loop
(class) [edit]

Execution domains

Forward progress guarantee

Defined in header <execution>
Defined in namespace std::execution
specifies a forward progress guarantee of execution agents created by the scheduler's associated execution resource
(enum) [edit]

Environments

Queries

Defined in header <execution>
asks a query object whether it should be forwarded through queryable adaptors
(customization point object)[edit]
asks a queryable object for its associated allocator
(customization point object)[edit]
asks a queryable object for its associated stop token
(customization point object)[edit]
asks a queryable object for its associated execution domain tag
(customization point object)[edit]
asks a queryable object for its associated scheduler
(customization point object)[edit]
asks a queryable object for a scheduler that can be used to delegate work to for the purpose of forward progress delegation
(customization point object)[edit]
obtains the completion scheduler associated with a completion tag from a sender's attributes
(customization point object)[edit]
asks a scheduler about its execution::forward_progress_guarantee
(customization point object)[edit]

Completion signatures

Coroutine utility

Core operations

Operation state

Defined in header <execution>
Defined in namespace std::execution
connects a sender with a receiver
(customization point object)[edit]
starts the asynchronous operation associated with an operation_state object
(customization point object)[edit]

Completion functions

These functions are called by senders to announce the completion of the work to their receivers.

Defined in header <execution>
Defined in namespace std::execution
value completion function indicating successful completion
(customization point object)[edit]
error completion function indicating that an error occurred during calculation or scheduling
(customization point object)[edit]
stopped completion function indicating that an operation ended before it could achieve success or failure
(customization point object)[edit]

Sender algorithms

Sender factories

A sender factory is a function that returns a sender and whose parameters have types for which the sender concept is false.

The following are sender factories:

Defined in header <execution>
Defined in namespace std::execution
Accepts a variadic number of arguments and returns a sender that, when connected and started, completes synchronously by passing the arguments to the receiver's value completion function
(customization point object)[edit]
Accepts a single argument and returns a sender that, when connected and started, completes synchronously by passing the argument to the receiver's error completion function
(customization point object)[edit]
creates a sender that completes immediately by calling its receiver's set_stopped
(customization point object)[edit]
creates a sender that queries its receiver's associated environment
(customization point object)[edit]
prepares a task graph for execution on a given scheduler
(customization point object)[edit]

Pipeable sender adaptors

Defined in header <execution>
Defined in namespace std::execution
helper base class template for defining a pipeable sender adaptor closure object
(class template) [edit]

Sender adaptors

A sender adaptor is a function returning a sender whose parameters include at least one whose type satisfies the sender concept, and for which the returned sender is a parent sender of the adaptor function's sender arguments.

The following are sender adaptors:

Defined in header <execution>
Defined in namespace std::execution
TODO
(customization point object)[edit]
TODO
(customization point object)[edit]
start the provided sender on an execution agent belonging to the execution resource associated with the provided scheduler
(customization point object)[edit]
TODO
(customization point object)[edit]
chains the task graph by the input sender with a node represents invoking the provided function with the values sent by the input sender as arguments
(customization point object)[edit]
chains the task graph by the input sender with a node representing invoking the provided function with the error sent by the input sender if an error occurred
(customization point object)[edit]
chains the task graph by the input sender with a node representing invoking the provided function with the stopped behavior by the input sender if a "stopped" signal is sent
(customization point object)[edit]
returns a sender which represents a node chained to the input sender, which when started, invokes the provided function with the values sent by the input sender as arguments
(customization point object)[edit]
returns a sender which represents a node chained to the input sender, which invokes the provided function with the error from the input sender, if occurred
(customization point object)[edit]
returns a sender which represents a node chained to the input sender, which invokes the provided function with the stop token from the input sender, if the "stopped" signal is sent
(customization point object)[edit]
creates a multi-shot sender that invokes the function with every index in the provided shape along with the values sent by the input sender. The sender completes once all invocations have completed, or an error has occurred
(customization point object)[edit]
if the provided sender is a multi-shot sender, returns that sender, otherwise, returns a multi-shot sender which sends values equivalent to the values sent by the provided sender
(customization point object)[edit]
completes once all of the input senders have completed
(customization point object)[edit]
TODO
(customization point object)[edit]
returns a sender which sends a variant of tuples of all the possible sets of types sent by the input sender
(customization point object)[edit]
returns a sender that maps the value channel to std::optional<std::decay_t<T>> and the stopped channel to std::nullopt
(customization point object)[edit]
returns a sender that maps the stopped channel to an error
(customization point object)[edit]

Sender consumers

A sender consumer is an algorithm that takes one or more senders as parameters and that does not return a sender.

Defined in header <execution>
Defined in namespace std::this_thread
blocks current thread until the specified sender completes and returns its async result
(customization point object)[edit]
blocks current thread until the specified sender with possibly multiple completion signatures completes and returns its async result
(customization point object)[edit]

Example

A version of this example is available on godbolt.org, where it uses stdexec, an experimental reference implementation of std::execution.

#include <cstdio>
#include <execution>
#include <string>
#include <thread>
#include <utility>
using namespace std::literals;
 
int main()
{
    std::execution::run_loop loop;
 
    std::jthread worker([&](std::stop_token st)
    {
        std::stop_callback cb{st, [&]{ loop.finish(); }};
        loop.run();
    });
 
    std::execution::sender auto hello = std::execution::just("hello world"s);
    std::execution::sender auto print
        = std::move(hello)
        | std::execution::then([](std::string msg)
        {
            return std::puts(msg.c_str());
        });
 
    std::execution::scheduler auto io_thread = loop.get_scheduler();
    std::execution::sender auto work = std::execution::on(io_thread, std::move(print));
 
    auto [result] = std::this_thread::sync_wait(std::move(work)).value();
 
    return result;
}

Output:

hello world

See also

(C++11)
runs a function asynchronously (potentially in a new thread) and returns a std::future that will hold the result
(function template) [edit]