CP013: What do we want the execution_context to be?

[AerialMantis]

In the current revision of the paper the execution_context is lightly defined, and simply provides a way construct a context around a particular part of the system topology in order to get an executor or allocator with affinity to specific resources.

After discussing this design with Chris K on the executor telecom he raised the very good point of what the execution_context is trying to be. Is it (a) the execution context; a polymorphic type which can serve as a wrapper for other concrete execution context types such as a thread pool, in the same way, the polymorphic executor does. Or is it (b) simply another concrete execution context type like static thread pool type is that is specifically designed for managing the resources of a discoverable topology.

Both of these are reasonable goals though they have very different scopes. If we were to aim for (a) then the scope is much larger, the execution_context must be fully compatible with all concrete execution context types, which would likely mean introducing explicit properties which can be mapped to the various properties of the concrete execution context types. If we were to aim for (b) then the scope is less, the execution_context can be limited to functionality which is required for managing resources discoverable in the topology. Additionally, if we were to aim for (b) we should probably rename the execution context type to something like resource_execution_context.

Personally, I think we should aim for (b) as it is a more limited scope, and trying to define a more generic execution context type means making the design compatible with many other concrete execution context types, which atm there are not many of. I feel it may be too early to try to define what a standard execution context should look like.

[Ruyk]

To me it seems that the executor context should be some sort of interface that implementations can use to "plug-in" into the executor context interface, so I lean towards A. I am not sure how B would be used. I guess at this point we need to define at least two separate implementations of execution contexts and see what they have in common. For example, you could imagine an implementation of an execution context that is a "thread pool" and another that contains a SYCL context. Both can be created towards a resource, and both can obtain executors from them. However, their implementations are very different.

[hcedwar]

I lean toward B - execution context is a concept for which specific types / instances will exist. E.g., async_execution_context and static_thread_pool are a couple of std::thread focused execution contexts in other papers.

[AerialMantis]

If we were to go down the route of having the execution context we define in P0796 be a concept which any execution context can satisfy this would mean that any execution context, even vendor specific ones could support the interface for affinity, and also remove the requirement for a concrete execution context type.

To do this we could introduce something like the following (note that this is based on the current revision of the paper, not inicluding any changes to the tolopogy structure):

An execution context satisfies the ExecutionResourceContext if it satisfies the following, where ec is an instance ofthe concrete execution context type EC and er is an instance of execution_resource:

Expression	Return type	Requirements
execution_context ec(er)	NA	Where er is an instance of execution_resource.
ec.execution_resource()	execution_resource	Returnsassociated execution context.
ec.executor()	EC::executor_type	Returns an executor which can execute with affinity to the associated execution resource.
ec.memory_resource()	EC::pmr_memory_resource_type	Returns a polymorphic memory resource which can allocate with affinity to the associated execution resource.

[AerialMantis]

There was support in Rapperswil for continuing down the route of having the execution context requirements be a concept.