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,765
Status Points:
16,765
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

8445 users have contributed to 31553 threads and 100398 posts to date.
In the past 24 hours, we have 10 new thread(s) 30 new posts(s), and 43 new user(s).

In the past 3 days, the most popular thread for everyone has been Lost in MKL The most posts were made to TBB on linux segfaulting The post with the most views is Hi,if you were using imsl yo

Please welcome our newest member nonamez