Affinity: Minor grammar fixes; add Note to this_thread::get_resource

Author: Mark Hoemmen

affinity/cpp-20/d0796r3.md

@@ -679,6 +679,9 @@ The free function `this_thread::get_resource` is provided for retrieving the `ex
 
 *Returns:* The `execution_resource` underlying the current thread of execution.
 
+> [*Note:* The `execution_resource` underlying the current thread of execution may not necessarily be reachable from "top-level" resources visible through `this_system`. *--end note*]
+
+
 # Future Work
 
 ## How should we define the execution context?
@@ -687,8 +690,8 @@ This paper currently defines the execution context as a concrete type which prov
 
 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]][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.
+* 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 specifically for its intended purpose, but would hinder interoperability with other concrete execution context types.
+* C) The execution context could be simply a concept, similar to `OnewayExecutor` or `BulkExecutor` for executors, that 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 the necessary interface for managing execution resources by simply implementing the requirements of the concept. It would also avoid defining any concrete or generic execution context type.
 
 | Straw Poll |
 |------------|
@@ -716,9 +719,9 @@ With the ability to place memory with affinity comes the ability to define algor
 
 ## Level of abstraction
 
-The current proposal provides an interface for querying whether an `execution_resource` can allocate and/or execute work, it can provide the concurrency it supports and it can provide a name. We also provide the `affinity_query` structure for querying the relative affinity metrics between two `execution_resource`s. However, this may not be enough information for users to take full advantage of the system. For example, they may also want to know what kind of memory is available or the properties by which work is executed. We decided that attempting to enumerate the various hardware components would not be ideal, as that would make it harder for implementors to support new hardware. We think a better approach would be to parameterize the additional properties of hardware such that hardware queries could be much more generic.
+The current proposal provides an interface for querying whether an `execution_resource` can allocate and/or execute work, it can provide the concurrency it supports and it can provide a name. We also provide the `affinity_query` structure for querying the relative affinity metrics between two `execution_resource`s. However, this may not be enough information for users to take full advantage of the system. For example, they may also want to know what kind of memory is available or the properties by which work is executed. We decided that attempting to enumerate the various hardware components would not be ideal, as that would make it harder for implementers to support new hardware. We think a better approach would be to parameterize the additional properties of hardware such that hardware queries could be much more generic.
 
-We may wish to mirror the design of the executors proposal and have a generic query interface using properties for querying information about an `execution_resource`. We expect that an implementation may provide additional nonstandard, implementation-specific queries.
+We may wish to mirror the design of the executors proposal [[22]][p0443r7] and have a generic query interface using properties for querying information about an `execution_resource`. We expect that an implementation may provide additional nonstandard, implementation-specific queries.
 
 | Straw Poll |
 |------------|
@@ -732,9 +735,9 @@ The current proposal requires that all `execution_resource`s are initialized bef
 |------------|
 | Should we support dynamically adding and removing `execution_resource`s at run time? |
 
-# Acknowledgements
+# Acknowledgments
 
-Thanks to Christopher Di Bella, Toomas Remmelg and Morris Hafner for their reviews and suggestions.
+Thanks to Christopher Di Bella, Toomas Remmelg, and Morris Hafner for their reviews and suggestions.
 
 # References