Move RFC to the supported

Signed-off-by: Isaev, Ilya <[email protected]>

Author: isaevil

rfcs/proposed/numa_support/README.md

@@ -132,7 +132,7 @@ See [sub-RFC for increased availability of NUMA API](tbbbind-link-static-hwloc.o
 
 ### Create NUMA-constrained arenas
 
-See [sub-RFC for creation of NUMA-constrained arenas](create-numa-arenas.md)
+This [sub-proposal is supported](../../supported/numa_support/create-numa-arenas.md).
 
 ### NUMA-aware allocation
 

rfcs/proposed/numa_support/create-numa-arenas.md renamed to rfcs/supported/numa_support/create-numa-arenas.md

@@ -1,10 +1,10 @@
 # API to simplify creation of task arenas constrained to NUMA nodes
 
-This sub-RFC proposes an API to ease creation of a one-per-NUMA-node set of task arenas.
+This describes describes an API to ease creation of a one-per-NUMA-node set of task arenas.
 
-## Introduction
+## Motivation
 
-The code example in the [overarching RFC for NUMA support](README.md) shows the likely
+The code example in the [overarching RFC for NUMA support](../../proposed/numa_support/README.md) shows the likely
 pattern of using task arenas to distribute computation across all NUMA domains on a system.
 Let's take a closer look at the part where arenas are created and initialized.
 
@@ -31,18 +31,18 @@ The default constructor of `task_arena` reserves a slot for an application threa
 at the last line explicitly overwrites it to 0 to allow TBB worker threads taking all the slots, however
 this nuance might be unknown and easy to miss, potentially resulting in underutilization of CPU resources.
 
-## Proposal
+## Implemented API
 
-We propose to introduce a special function to create the set of task arenas, one per NUMA node on the system.
+A special function is introduced to create the set of task arenas, one per NUMA node on the system.
 The initialization code equivalent to the example above would be:
 
 ```c++
   std::vector<tbb::task_arena> arenas = tbb::create_numa_task_arenas();
   std::vector<tbb::task_group> task_groups(arenas.size());
 ```
 
-The rest of the code in that example might be rewritten with the API proposed in
-[Waiting in a task arena](../task_arena_waiting/readme.md):
+The rest of the code in that example might be rewritten with the API for
+[waiting in a task arena](../task_arena_waiting/readme.md):
 
 ```c++
   // enqueue work to all but the first arena, using the task groups to track work
@@ -71,14 +71,14 @@ The function has the following signature:
 
 namespace tbb {
     std::vector<tbb::task_arena> create_numa_task_arenas(
-        task_arena::constraints other_constraints = {},
+        task_arena::constraints constraints_ = {},
         unsigned reserved_slots = 0
     };
 }
 ```
 
 It optionally takes a `constraints` argument to change default arena settings such as maximal concurrency
-(the upper limit on the number of threads), core type etc.; the `numa_id` value in `other_constraints`
+(the upper limit on the number of threads), core type etc.; the `numa_id` value in `constraints_`
 is ignored. The second optional argument allows to override the number of reserved slots, which by default
 is 0 (unlike the `task_arena` construction default of 1) for the reasons described in the introduction.
 
@@ -114,7 +114,7 @@ The following critics was provided in the RFC discussion:
 
 - It might be confusing that a single `constraints` object is used to generate multiple arenas,
   especially with part of it (`numa_id`) being ignored.
-- The proposed API addresses just one, albeit important, use case for creating a set of arenas.
+- The API addresses just one, albeit important, use case for creating a set of arenas.
 
 See the "universal function" alternative below for related considerations.
 
@@ -175,7 +175,7 @@ its downsides:
 - It seems very specialized, capable to only address specific and quite narrow set of use cases.
 - Arenas are pre-initialized and so could not be adjusted after creation.
 
-Our proposal, instead, aims at a single usability aspect with incremental improvements/extensions
+This API, instead, aims at a single usability aspect with incremental improvements/extensions
 to the existing oneTBB classes and usage patterns, leaving other aspects to complementary proposals.
 Specifically, the [Waiting in a task arena](../task_arena_waiting/readme.md) RFC improves the joint
 use of a task arena and a task group to submit and wait for work. Combined, these extensions will
@@ -202,7 +202,7 @@ would serve as a pattern for generating a set of constraints bound to NUMA domai
 Using a function to generate arena parameter sets seems even more flexible comparing to a description
 language, as that function would be not limited in which parameters to alter, and how.
 
-Compared to the proposal, this approach would necessarily be more verbose because of the need to
+This approach would necessarily be more verbose because of the need to
 describe or generate a set of constraints. That could however be mitigated for common use cases
 with presets provided by the library allowing for a reasonably concise code. For example:
 ```c++
@@ -215,10 +215,10 @@ extra complexity. As of now, we know just a few arena set patterns with potentia
 besides NUMA arenas, we can think of splitting CPU resources by core type and of creating a set of
 arenas with different priorities. We do not however recall any requests to simplify these use cases.
 
-## Open questions
+## Future Questions
 - Instead of a free-standing function in namespace `tbb`, should we consider
   a static member function in class `task_arena`?
-- The proposal does not consider arena priority, simply keeping the default `priority::normal`.
+- At this point arena priority parameter is not considered, simply keeping the default `priority::normal`.
   Are there use cases for pre-setting priorities? Similarly for the experimental thread leave policy.
 - Are there more practical use cases which could justify the universal function approach?
 - Need to consider alternatives to silently ignoring `numa_id` in constraints, such as an exception

test/tbb/test_arena_constraints.cpp

@@ -114,10 +114,11 @@ TEST_CASE("Test reserved slots argument in create_numa_task_arenas") {
   auto numa_task_arenas = tbb::create_numa_task_arenas();
   if (numa_task_arenas.size() > 1) {
     for (auto& ta : numa_task_arenas) {
-      utils::SpinBarrier barrier {(std::size_t)ta.max_concurrency()};
+      utils::SpinBarrier barrier {(std::size_t)ta.max_concurrency() + 1};
       for (int i = 0; i < ta.max_concurrency(); ++i) {
         ta.enqueue([&barrier] { barrier.wait(); });
       }
+      barrier.wait();
     }
   }