A newbie question regarding parallel_while knockoff and tbb::task::self()

[sagnak]

I was revisiting a code which had a parallel_while and wanted to do same thing explicitly instead of using parallel_while (since that being deprecated). What I understood from the source for parallel_while is that it creates an empty task and makes every new task a child of that root empty task and waits on the root, which acts like a barrier. In my code to achieve the same, I have created a root empty task, generated by the master thread. Then, I allow multiple threads to create new tasks and add it as a child to the root. When I want to join, I wait on the root empty task. This works fine, however I am having trouble understanding why, my assumption would be that it should not have. Let me elaborate my confusion below.

Now when a thread wants to add a new child to the root, it needs a running task on that thread to do so (if I am not mistaken). My question is: How does a thread make a task an additional child of the root before starting running a task? When an initialize the task scheduler every thread should have null for tbb::task::self() (The master thread is running but since what it is doing is not a tbb::task, self() should be null for that, too). If that is the case, how is the very first job start executing?

Sagnak

[RafSchietekat]

Reference (Open Source).pdf revision 1.13 (may not be latest) says for task::self(): "If the calling thread is a user-created thread that is not running any task, self() returns a reference to an implicit dummy task associated with the thread." So if you want to call task::allocate_additional_child_of() from your own thread, make sure it has an active task_scheduler_init registration, and use task::self().

(Added) It does leave me wondering what this does for ownership, because the owner may go away or become unregistered during the lifetime of the task. What does ownership do besides affecting the outcome of is_stolen_task()?

[sagnak]

Yep, this makes sense. I was using the book as the reference which did not have the line. In the source code for ::self(), there is an assertion for the innermost_running_task which is initialized to null in the constructor for scheduler but it can get assigned the dummy_task on its execution.

Thanks


Quoting - Raf Schietekat

Reference (Open Source).pdf revision 1.13 (may not be latest) says for task::self(): "If the calling thread is a user-created thread that is not running any task, self() returns a reference to an implicit dummy task associated with the thread." So if you want to call task::allocate_additional_child_of() from your own thread, make sure it has an active task_scheduler_init registration, and use task::self().

(Added) It does leave me wondering what this does for ownership, because the owner may go away or become unregistered during the lifetime of the task. What does ownership do besides affecting the outcome of is_stolen_task()?