Affinity: Update p0443 reference; remove ref-counting language

Author: Mark Hoemmen

affinity/cpp-20/d0796r3.md

@@ -114,18 +114,19 @@ In this paper we describe the problem space of affinity for C++, the various cha
 * How to bind execution and allocation particular execution resource(s).
 * What kind of and level of interface(s) should be provided by C++ for affinity.
 
-Wherever possible, we also evaluate how an affinity-based solution could be scaled to support both distributed and heterogeneous systems.
+Wherever possible, we also evaluate how an affinity-based solution could be scaled to support both distributed and heterogeneous systems. We also have addressed some aspects of dynamic topology discovery.
 
 There are also some additional challenges which we have been investigating but are not yet ready to be included in this paper, and which will be presented in a future paper:
 
 * How to migrate memory work and memory allocations between execution resources.
-* How to support dynamic topology discovery and fault tolerance.
+* More general cases of dynamic topology discovery.
+* Fault tolerance, as it relates to dynamic topology.
 
 ### Querying and representing the system topology
 
 The first task in allowing C++ applications to leverage memory locality is to provide the ability to query a *system* for its *resource topology* (commonly represented as a tree or graph) and traverse its *execution resources*.
 
-The capability of querying underlying *execution resources* of a given *system* is particularly important towards supporting affinity control in C++. The current proposal for executors [[22]][p0443r4] leaves the *execution resource* largely unspecified. This is intentional: *execution resources* will vary greatly between one implementation and another, and it is out of the scope of the current executors proposal to define those. There is current work [[23]][p0737r0] on extending the executors proposal to describe a typical interface for an *execution context*. In this paper a typical *execution context* is defined with an interface for construction and comparison, and for retrieving an *executor*, waiting on submitted work to complete and querying the underlying *execution resource*. Extending the executors interface to provide topology information can serve as a basis for providing a unified interface to expose affinity. This interface cannot mandate a specific architectural definition, and must be generic enough that future architectural evolutions can still be expressed.
+The capability of querying underlying *execution resources* of a given *system* is particularly important towards supporting affinity control in C++. The current proposal for executors [[22]][p0443r7] mentions execution resources in passing, but leaves the term largely unspecified. This is intentional: *execution resources* will vary greatly between one implementation and another, and it is out of the scope of the current executors proposal to define those. There is current work [[23]][p0737r0] on extending the executors proposal to describe a typical interface for an *execution context*. In this paper a typical *execution context* is defined with an interface for construction and comparison, and for retrieving an *executor*, waiting on submitted work to complete and querying the underlying *execution resource*. Extending the executors interface to provide topology information can serve as a basis for providing a unified interface to expose affinity. This interface cannot mandate a specific architectural definition, and must be generic enough that future architectural evolutions can still be expressed.
 
 Two important considerations when defining a unified interface for querying the *resource topology* of a *system*, are (a) what level of abstraction such an interface should have, and (b) at what granularity it should describe the typology's *execution resources*. As both the level of abstraction of an *execution resource* and the granularity that it is described in will vary greatly from one implementation to another, it’s important for the interface to be generic enough to support any level of abstraction. To achieve this we propose a generic hierarchical structure of *execution resources*, each *execution resource* being composed of other *execution resources* recursively. Each *execution resource* within this hierarchy can be used to place memory (i.e., allocate memory within the *execution resource’s* memory region), place execution (i.e. bind an execution to an *execution resource’s execution agents*), or both.
 
@@ -227,7 +228,7 @@ This feature could be easily scaled to heterogeneous and distributed systems, as
 
 ## Overview
 
-In this paper we propose an interface for querying and representing the execution resources within a system, querying the relative affinity metric between those execution resources, and then using those execution resources to allocate memory and execute work with affinity to the underlying hardware. The interface described in this paper builds on the existing interface for executors and execution contexts defined in the executors proposal [[22]][p0443r4].
+In this paper we propose an interface for querying and representing the execution resources within a system, querying the relative affinity metric between those execution resources, and then using those execution resources to allocate memory and execute work with affinity to the underlying hardware. The interface described in this paper builds on the existing interface for executors and execution contexts defined in the executors proposal [[22]][p0443r7].
 
 ### Interface granularity
 
@@ -473,11 +474,11 @@ A *thread of execution* can be requested to bind to a particular `execution_reso
 
 The `bulk_execution_affinity_t` property describes what guarantees executors provide about the binding of *execution agent*s to the underlying *execution resource*s.
 
-bulk_execution_affinity_t provides nested property types and objects as described below. These properties are behavioral properties as described in [[22]][p0443r4] so must adhere to the requirements of behavioral properties and the requirements described below.
+bulk_execution_affinity_t provides nested property types and objects as described below. These properties are behavioral properties as described in [[22]][p0443r7] so must adhere to the requirements of behavioral properties and the requirements described below.
 
 | Nested Property Type | Nested Property Name | Requirements |
 |----------------------|----------------------|--------------|
-| bulk_execution_affinity_t::none_t | bulk_execution_affinity_t::none | A call to an executor's bulk execution function may or may not bind  the *execution agent*s to the underlying *execution resource*s. The affinity binding pattern may or may not be consistent across invocations of the executor's bulk execution function.  |
+| bulk_execution_affinity_t::none_t | bulk_execution_affinity_t::none | A call to an executor's bulk execution function may or may not bind the *execution agent*s to the underlying *execution resource*s. The affinity binding pattern may or may not be consistent across invocations of the executor's bulk execution function.  |
 | bulk_execution_affinity_t::scatter_t | bulk_execution_scatter_t::scatter | A call to an executor's bulk execution function must bind the *execution agent*s to the underlying *execution resource*s such that they are distributed across the *execution resource*s where each *execution agent* far from it's preceding and following *execution agent*s. The affinity binding pattern must be consistent across invocations of the executor's bulk execution function. |
 | bulk_execution_affinity_t::compact_t | bulk_execution_compact_t::compact | A call to an executor's bulk execution function must bind the *execution agent*s to the underlying *execution resource*s such that they are in sequence across the *execution resource*s where each *execution agent* close to it's preceding and following *execution agent*s. The affinity binding pattern must be consistent across invocations of the executor's bulk execution function. |
 | bulk_execution_affinity_t::balanced_t | bulk_execution_balanced_t::balanced | A call to an executor's bulk execution function must bind the *execution agent*s to the underlying *execution resource*s such that they are in sequence and evenly spread across the *execution resource*s where each *execution agent* is close to it's preceding and following *execution agent*s and all *execution resource*s are utilized. The affinity binding pattern must be consistent across invocations of the executor's bulk execution function. |
@@ -492,7 +493,7 @@ bulk_execution_affinity_t provides nested property types and objects as describe
 
 The `execution_resource` class provides an abstraction over a system's hardware, that can allocate memory and/or execute lightweight execution agents. An `execution_resource` can represent further `execution_resource`s. We say that these `execution_resource`s are *members of* this `execution_resource`.
 
-> [*Note:* The `execution_resource` is required to be implemented such that the underlying software abstraction is initialized when the `execution_resource` is constructed, maintained through reference counting, and cleaned up on destruction of the final reference. *--end note*]
+> [*Note:* Creating an `execution_resource` may require initializing the  underlying software abstraction when the `execution_resource` is constructed, in order to discover other `execution_resource`s accessible through it. However, an `execution_resource` is nonowning. *--end note*]
 
 ### `execution_resource` constructors
 
@@ -545,7 +546,7 @@ The `execution_context` class provides an abstraction for managing a number of l
 
     using executor_type = see-below;
 
-*Requires:* `executor_type` is an implementation defined class which satisfies the general executor requires, as specified by P0443r5.
+*Requires:* `executor_type` is an implementation defined class which satisfies the general executor requires, as specified by [[22]][p0443r7].
 
     using pmr_memory_resource_type = see-below;
 
@@ -685,7 +686,7 @@ The free function `this_thread::get_resource` is provided for retrieving the `ex
 This paper currently defines the execution context as a concrete type which provides the essential interface requires to be constructed from an `execution_resource` and to provide an affinity-based `allocator` or `pmr::memory_resource` and `executor`.
 
 However going forward there are a few different directions the execution context could take:
-* A) The execution context could be **the** standard execution context type, which can be used polymorphically in place of any concrete execution context type in a similar way to the polymorphic executor [[22]][p0443r4]. This approach allows it to interoperate well with any concrete execution context type, however it may be very difficult to define exactly what this type should look like as the different kinds of execution contexts are still being developed and all the different requirements are still to be fully understood.
+* A) The execution context could be **the** standard execution context type, which can be used polymorphically in place of any concrete execution context type in a similar way to the polymorphic executor [[22]][p0443r7]. This approach allows it to interoperate well with any concrete execution context type, however it may be very difficult to define exactly what this type should look like as the different kinds of execution contexts are still being developed and all the different requirements are still to be fully understood.
 * B) The execution context could be a concrete executor type itself, used solely for the purpose of being constructed from and managing a set of `execution_resource`s. This approach would allow the execution context to be tailored specific for it's original purpose, however it would be more difficult to support interoperability with other concrete execution context types.
 * C) The execution context could be simply a concept, similar to `OnewayExecutor` or `BulkExecutor`, for executors, where it requires the execution context type to provide the required interface for managing *execution_resource*s. This approach would allow for any concrete execution context type to support necessary interface for managing execution resources by simply implementing the requirements of the concept, and would avoid defining any concrete or generic execution context type.
 
@@ -799,8 +800,9 @@ Thanks to Christopher Di Bella, Toomas Remmelg and Morris Hafner for their revie
 [lstopo]: https://www.open-mpi.org/projects/hwloc/lstopo/
 [[21]][lstopo] Portable Hardware Locality Istopo
 
-[p0443r4]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0443r4.html
-[[22]][p0443r4] A Unified Executors Proposal for C++
+[p0443r7]:
+http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0443r7.html
+[[22]][p0443r7] A Unified Executors Proposal for C++
 
 [p0737r0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0737r0.html
 [[23]][p0737r0] P0737r0 : Execution Context of Execution Agents