[thread.stoptoken.intro]

The concepts stoppable-source, stoppable_token, and stoppable-callback-for specify the required syntax and semantics of shared access to a stop state.

Any object modeling stoppable-source, stoppable_token, or stoppable-callback-for that refers to the same stop state is an associated stoppable-source, stoppable_token, or stoppable-callback-for, respectively.

An object of a type that models stoppable_token can be passed to an operation that can either

(3.1)
actively poll the token to check if there has been a stop request, or
(3.2)
register a callback that will be called in the event that a stop request is made.

A stop request made via an object whose type models stoppable-source will be visible to all associated stoppable_token and stoppable-source objects.

Once a stop request has been made it cannot be withdrawn (a subsequent stop request has no effect).

Callbacks registered via an object whose type models stoppable-callback-for are called when a stop request is first made by any associated stoppable-source object.

The types stop_source and stop_token and the class template stop_callback implement the semantics of shared ownership of a stop state.

The last remaining owner of the stop state automatically releases the resources associated with the stop state.

An object of type inplace_stop_source is the sole owner of its stop state.

An object of type inplace_stop_token or of a specialization of the class template inplace_stop_callback does not participate in ownership of its associated stop state.

[Note 1:

They are for use when all uses of the associated token and callback objects are known to nest within the lifetime of the inplace_stop_source object.

— end note]