Community
cancel
Showing results for 
Search instead for 
Did you mean: 
trevorthomson
Beginner
113 Views

set_ref_count() question

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_K_Intel3
Employee
113 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.
trevorthomson
Beginner
113 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!
RafSchietekat
Black Belt
113 Views

Would it be possible to say something about this deadlock situation, and how you think TBB affects it?
Reply