CP0013: Make minor correctiosn to affinity paper.

* Fix ordering of sections.
* Remove std::vector of references from proposed interface.

Author: AerialMantis

affinity/cpp-20/d0796r1.md

@@ -1,6 +1,6 @@
 # D0796r1: Supporting Heterogeneous & Distributed Computing Through Affinity
 
-**Date: 2017-10-16**
+**Date: 2017-11-27**
 
 **Audience: SG1, SG14**
 
@@ -182,20 +182,20 @@ Below is a proposed interface for querying a **system** for its **resource topol
 
 ```cpp
 namespace std::this_system {
-  std::vector<execution_resource &> resources();
+  execution_resource &resource();
 }
 ```
 *Listing 3: Interface for querying the execution resources available within a system*
 
-The **resources** function in the `this_system` namespace will return all **execution resources available** to the current system.
+The **resource** function in the `this_system` namespace will return the root **execution resource** of the current system.
 
 Below is an example of the interface for querying the **execution resources** available to the entire system and printing out the names of each **execution resource**.
 
 ```cpp
-auto &resources = std::execution::this_system::resources();
+auto &resource = std::execution::this_system::resource();
 
-for (auto &r : resources) {
-    std::cout << r.name()  << std::endl;
+for (int i = 0 ; i < partition_size(); i++) {
+    std::cout << resource.partition(i).name()  << std::endl;
 }
 ```
 *Listing 4: Example of querying the execution resources available within a system*
@@ -245,29 +245,6 @@ for (int i = 0; i < resource.partition_size(); i++) {
 | Should the interface provide a way of creating an execution context from an execution resource? |
 | *Is what is defined here a suitable solution?* |
 
-## Binding Execution and Allocation to a Partition
-
-When creating an **execution context** from a given **execution resource**, the executors and allocators associated with it are bound to that **execution resource**. For example: when creating an **execution resource** from a CPU socket resource, all executors associated with the given socket will spawn execution agents with affinity to the socket partition of the system.
-
-```cpp
-auto cList = std::execution::this_system::resources();
-// FindASocketResource is a user-defined function that finds a 
-// resource that is a CPU socket in the given resource list
-auto& socket = findASocketResource(cList);
-execution_contexteC{socket} // Associated with the socket
-auto executor = eC.executor(myFunctor); // By transitivity, associated with the socket too
-auto socketAllocator = eC.allocator(); // Retrieve an allocator to the closest memory node
-std::vector<int, socketAllocator> v1(100);
-std::generate(par.on(executor), std::begin(v1), std::end(v1), std::rand);
-```
-*Listing 8: Example of allocating with affinity to an execution resource*
-
-The construction of an **execution context** on a component implies affinity (where possible) to the given resource. This guarantees that all executors created from that **execution context** can access the resources and the internal data structures requires to guarantee the placement of the processor.
-
-Only developers that care about resource placement need to care about obtaining executors and allocations from the correct **execution context** object. Existing code for vectors and STL (including Parallel STL interface) remains unaffected.
-
-If a particular policy or algorithm requires to access placement information, the resources associated with the passed executor can be retrieved via the link to the **execution context**.
-
 ### Importance of topology discovery
 
 For traditional single CPU systems the execution resources reasoned about using standard constructs such as std::thread, std::this_thread and thread local storage. This is because the C++ memory model requires that  a system have **at least one thread of execution, some memory and some I/O capabilities**. This means that for these systems some assumptions can be made about the topology could be made during at compile-time, for example the fact that developers can query always the hardware concurrency available as there is always at least 1 thread or the fact that you can always use thread local storage.
@@ -314,6 +291,29 @@ The relative position of two components in the topology is not necessary and ind
 
 This feature could be easily scaled to heterogeneous and distributed systems as the relative affinity between components can apply to discrete heterogeneous and distributed systems as well.
 
+## Binding Execution and Allocation to a Partition
+
+When creating an **execution context** from a given **execution resource**, the executors and allocators associated with it are bound to that **execution resource**. For example: when creating an **execution resource** from a CPU socket resource, all executors associated with the given socket will spawn execution agents with affinity to the socket partition of the system.
+
+```cpp
+auto cList = std::execution::this_system::resources();
+// FindASocketResource is a user-defined function that finds a 
+// resource that is a CPU socket in the given resource list
+auto& socket = findASocketResource(cList);
+execution_contexteC{socket} // Associated with the socket
+auto executor = eC.executor(myFunctor); // By transitivity, associated with the socket too
+auto socketAllocator = eC.allocator(); // Retrieve an allocator to the closest memory node
+std::vector<int, socketAllocator> v1(100);
+std::generate(par.on(executor), std::begin(v1), std::end(v1), std::rand);
+```
+*Listing 8: Example of allocating with affinity to an execution resource*
+
+The construction of an **execution context** on a component implies affinity (where possible) to the given resource. This guarantees that all executors created from that **execution context** can access the resources and the internal data structures requires to guarantee the placement of the processor.
+
+Only developers that care about resource placement need to care about obtaining executors and allocations from the correct **execution context** object. Existing code for vectors and STL (including Parallel STL interface) remains unaffected.
+
+If a particular policy or algorithm requires to access placement information, the resources associated with the passed executor can be retrieved via the link to the **execution context**.
+
 # Future Work
 
 ### Migrating data from memory allocated in one partition to another

data-movement/index.md

@@ -9,7 +9,7 @@
 | Last update | 28 August 2017 |
 | Reply-to | Michael Wong <[email protected]> |
 | Original author | Ruyman Reyes <[email protected]> |
-| Contributors | Gordon Brown <[email protected]>, Michael Wong <[email protected]>, Hartmut Kaiser <[email protected] > |
+| Contributors | Gordon Brown <[email protected]>, Michael Wong <[email protected]>, Hartmut Kaiser <[email protected]> |
 
 ## Overview