Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

set_ref_count() question

trevorthomson
Beginner
628 Views
Hi,

I'm curious about when a parent task is resumed when I use set_ref_count (n) vs. set_ref_count (n+1) where n is the number of child tasks.

For example,

// Note: this code is within a task (called 'parent' for this discussion) spawned by parallel_for()...

tbb::task & task = tbb::task::self ();
myTask * a = new (task.allocate_child ()) myTask (/*...*/);
myTask * b = new (task.allocate_child ()) myTask (/*...*/);
task.set_ref_count (3);
task.spawn (a);
task.spawn_and_wait_for_all (b);

// do lots of stuff--very difficult to write a continuation task for it

My understanding is that 'set_ref_count (3)' will push 'parent' onto the thread's deque once the children complete, and the thread could potentially go do something else prior to resuming 'parent'. I'd like 'parent' to resume immediately, so if I use 'set_ref_count (2)' instead, will 'parent' be the next task executed (or resumed, in this case) by the thread?

Thanks!
0 Kudos
3 Replies
Alexey-Kukanov
Employee
628 Views
Your code is correct for what you want to achieve.

wait_for_all calls return when ref-count of the parent becomes 1, while a continuation task is spawned (or possiblyexecuted) when its ref-count becomes 0.

Therefore, if you want to resume the "parent" task after its children are done, you need to use set_ref_count(n+1), i.e. 3 in the above case. However the parent task will not necessary resume immediately, as the thread might have stolen and be executing another task.
0 Kudos
trevorthomson
Beginner
628 Views
Thanks for the clarification. The thread definately steals a task in my case and unfortunatly deadlocks--we'll have to rethink our approach. Thanks!
0 Kudos
RafSchietekat
Valued Contributor III
628 Views
Would it be possible to say something about this deadlock situation, and how you think TBB affects it?
0 Kudos
Reply