Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
sagnak
Total Points:
30
Registered User
July 10, 2009 1:05 PM PDT
A newbie question regarding parallel_while knockoff and tbb::task::self()
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
Raf Schietekat
Total Points:
16,565
Status Points:
16,565
Black Belt
July 12, 2009 11:11 AM PDT
Rate
 
#1
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
Total Points:
30
Registered User
July 13, 2009 8:00 AM PDT
Rate
 
#2 Reply to #1

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()?





Intel Software Network Forums Statistics

8285 users have contributed to 31229 threads and 99107 posts to date.
In the past 24 hours, we have 9 new thread(s) 39 new posts(s), and 55 new user(s).

In the past 3 days, the most popular thread for everyone has been comparison cilk++, openmp, pthreads first results The most posts were made to comparison cilk++, openmp, pthreads first results The post with the most views is Very amusing...  Escalated as

Please welcome our newest member tvinni