set_ref_count() question

[trevorthomson]

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!

[Alexey-Kukanov]

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]

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]

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