P2206R0
Executors Thread Pool review report

1. Issues

1.1. Design issues

• Issue #526 on GitHub: “2.5.2.3 Add attach_and_wait() method”

  Add attach_and_wait method to allow the thread to be attached to the static_thread_pool and help with work while it's waiting for the completion

• Issue #528 on GitHub: “Consider adding the method that indicates that static_thread_pool is stopped”

  Consider adding the method that indicates that static_thread_pool is stopped meaning that it doesn't accept new work.

• Issue #529 on GitHub: “Scheduler of static_thread_pool should have the same set of properties as sender does”

  Changes required in "2.5.2.4", "2.5.3" and "2.5.3.3"

  If that issue is applied need to explicitly say that sender returned by the scheduler has the same values of properties established as the scheduler itself

• Issue #530 on GitHub: “State the relation between the scheduler_type and executor_type”

  Three options raised during the review:

  • Always the same type
  • Can be same type
  • Never same type

  Potential implications: constrained overload choosing. One overload is constrained by scheduler concept and another one by executor concept. If the types are the same it is always ambiguity. It can be potentially solved by introducing the different types.

  Possibly there are other implications, deeper investigation is needed.

• Issue #535 on GitHub: “Consider adding is_always_equal trait for executors/schedulers/senders”

  Consider adding mentioned trait similar to the one that the allocators have to identify if schedulers/executors/senders are always equal at compile-time

• Issue #538 on GitHub: “2.2.8. requires(E &&e) should be requires(const E &e)”

  Please also check how it affects other parts of the paper. Probably 2.5.2.4 should be updated as well.

  In 2.2.8. there is a typo as well. S should be used instead of E. So, at the end it should look like const S& within requires-expression

• Issue #539 on GitHub: “Consider whether to add a submit member function to the static_thread_pool sender type.”

  Adding submit member function to static_thread_pool sender type allows implementations to customize the behavior according to their needs, rather then relying on the default behavior of std::execution::submit.

  For example implementation of static_thread_pool may want to customize how sender works with Allocator

• Issue #540 on GitHub: “Investigate the necessity of operator== for static_thread_pool senders and for senders in general”

  Probably the senders can be EquallyComparable optionally. If it's the case the senders could probably have special meaning as for the allocators. One of the options: "If senders are EquallyComparable and operator== returns true it means that they are interchangeable"

• Issue #542 on GitHub: “Consider third option for outstanding_work_t property”

  Please investigate if it worth to have the third option for outstanding_work_t (like outstanding work.possibly or outstanding_work.unknown)

• Issue #543 on GitHub: “Investigate the right default for outstanding_work_t property”

  Please take into account #542

• Issue #544 on GitHub: “Consider the third option for relationship_t property”

  Please investigate if it worth to have the third option for relationship_t (like relationship.unknown)

• Issue #545 on GitHub: “Investigate the right default for relationship_t property”

  Please take into account #544

• Issue #552 on GitHub: “Investigate whether vendors can add their own properties via free functions but not member functions.”

  Sub-question: clarify whether implementations are allowed to provide additional overloads of require.

  If adding user overloads is allowed consider whether vendor properties must always result in a new executor/scheduler type.

• Issue #554 on GitHub: “Investigate the possibility to simplify allocator_t property”

  Please investigate if overloads with ProtoAllocator can be changed somehow to query/require both user set up allocator or default one

  If the first suggestion would be applied overloads with allocator_t<void> seem unnecessary

• Issue #555 on GitHub: “Describe when and how submit/execute/other similar methods use allocator”

  Possible option to go is to use the same approach as Container requirements do.

  Larger question:

  • Are implementations of static_thread_pool allowed to do not allocate any memory at all under implementation-defined conditions (e.g. a thread pool could use a preallocated circular buffer that is "common" rather than "per function", and only touch the allocator if it runs out of space.)?
  • If the static_thread_pool does need to allocate some per-function state that is not available , is implementation required to use the specified allocator?

  Note: implementations may want to provide a submit member function for senders to avoid the heap allocation.

1.2. Wording issues

• Issue #521 on GitHub: “2.5.2.3 Worker management. Make attach look like the code and add parentheses”

  In stop() method description in the following sentence the attach mentioning should be fixed. "Subsequent invocations to attach complete immediately."

• Issue #522 on GitHub: “Define better term instead of function objects (work-item, task, etc.)”

  Paper uses function objects in several places in the static thread pool wording. Need to define a term (like work item or task) instead of function object.

• Issue #523 on GitHub: “Consider better name for static_thread_pool”

  static_thread_pool seems a bit off, since the size is sort of dynamic.

• Issue #524 on GitHub: “Investigate why the wording has been changed and identify the right one”

  commit 9a88bfc

  Before:

  -A static_thread_pool's threads execute execution agents created via its associated executors with forward progress guarantee delegation. [Note: Forward progress is delegated to an execution agent for its lifetime. Because static_thread_pool guarantees only parallel forward progress to execution agents created via its executors, forward progress delegation does not apply to execution agents which have not yet started executing their first execution step. --end note]

  After:

  +A static_thread_pool's threads run execution agents with forward progress guarantee delegation. [Note: Forward progress is delegated to an execution agent for its lifetime. Because static_thread_pool guarantees only parallel forward progress to running execution agents; i.e., execution agents which have run the first step of the function object. --end note]

• Issue #525 on GitHub: “Provide and example for untracked executor with no more work expected”

  Provide an example where a work-item scheduled by an untracked executor can indicate that no more work is expected.

• Issue #527 on GitHub: “Add wording how 2.5.2.3 "Worker management" functions interact with each other”

  Add wording how 2.5.2.3 "Worker management" functions interact with each other and what are implications to other static_thread_pool methods. Take into account concurrent use-cases.

  Example 1: What would happen if after wait() function returns user calls executor().execute() methods on the static_thread_pool` object?

  Example 2: If some thread calls wait() and another thread calls stop() that would discard the work in the thread pool

• Issue #531 on GitHub: “Change descriptive type C to something more specific”

  Probably introduce the Exposition Only type to have better experience with reading the paper

• Issue #532 on GitHub: “Remove oneway property mentioning from everywhere”
• Issue #533 on GitHub: “2.5.3 Schedule() method should be in the synopsis”

  The similar modifications should be done for "Executor Types" and "Sender types" sections.

• Issue #534 on GitHub: “Explore is operator!= should be explicitly listed”

  Since C++20 user has operator!= for free if operator== is explicitly defined.

  Request for the exploration is relevant to the whole paper where both operator== and operator!= are defined

• Issue #536 on GitHub: “Remove 2.5.3.5”

  Related issue: #533

  The similar modifications should be done for "Executor Types" and "Sender types" sections.

• Issue #537 on GitHub: “Consider alternative name instead of schedule()”
• Issue #541 on GitHub: “Make sure that P0443 clearly states that receiver functions cannot be called until start is called”
• Issue #546 on GitHub: “Provide stronger guarantees on outstanding_work.untracked”

  Depends on #542. If the outstanding_work.possibly (or something) is accepted then need to make sure that outstanding_work.unknown provides strong enough guarantees about deadlock.

• Issue #547 on GitHub: “Consider alternative naming for relationship_t property and nested properties for that”
• Issue #548 on GitHub: “Consider alternative naming for outstanding_work_t property and nested properties for that”
• Issue #549 on GitHub: “Make sure P0443 does not refer to concept changing properties anymore”
• Issue #550 on GitHub: “Introduce the "Properties" term of art in P1393”

  Consider adding established property term into P1393 and have the reference to that in P0443.

  Related issue: #506.

• Issue #551 on GitHub: “Introduce the "behavioral properties" term of art”

  Identify if it should be added into P0443 or into P1393.

  Current suggestion is to add it into P0443 because only executors introduce such model with nested properties. Probably add note that it may become the wider term and potentially may be added to P1393

• Issue #553 on GitHub: “Consider consolidation of schedulers/senders type requirements on the P0443 level”

  If #529 is applied please find the way to consolidate schedulers/senders type requirements on the P0443 level

  Something like: "The X,Y,Z classes conform to the following specification..."

  Possible option to go is to use the same approach as Container requirements do

• Issue #556 on GitHub: “Make sure the exception_ptr is the the error type for the static_thread_pool sender”
• Issue #557 on GitHub: “Consider having the description of behavioral properties in one place use references to that”

  Example: "Returns: An sender object of an unspecified type conforming to these specifications, associated with the same thread pool as *this, and having the requested property established. When the requested property is part of a group that is defined as a mutually exclusive set, any other properties in the group are removed from the returned sender object. All other properties of the returned sender object are identical to those of *this."

  It seems like the description of the behavioral properties mostly. It can be described in one place and then references to it can be used to do not duplicate the information

1.3. Issue references

• Issue #506 on GitHub: “What does "established property" mean?”

  From the Executors Property review group: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2183r0.html#established

  Many places in the paper use the phrase "property already established" or something similar. But there is no precise definition of what "established" means. The paper should provide a definition, so that implementations (and users who write their own executor types) have a better understanding of what to implement.

  (See the link for more discussion.)