Task Scheduler

[zweistein]

Is there a way to say tasks should not be deallocated after execution? Because i want to spawn some tasks again and again without ever delete them.

I want to use the scheduler as kind of a threadpool.

lg

[zweistein]

Ok, i got it to work through a call torecycle_to_reexecute();

However, now it dont seem to run parallel. Do Tasks allocated withtbb::task::allocate_root() for any reason run not parallel?

[Dmitry_Vyukov]

check out:
tbb/examples/task/tree_sum/OptimizedParallelSumTree.cpp
and in particular, recycle_as_continuation().

[zweistein]

Thanks for the reply.

I checked continuation now from the tutorial.pdf. Here is the problem i see:

I want to spawn 100 tasks. the last task that is executed spawns another 100 tasks. From those new 100 tasks the last one again spawns the first 100 tasks. this is repeated "forever".

When i spawn a ContinuationTask, it wont get deleted until all ChildTasks from the ContinuationTasks are ready. So i guess i will run into a stack overflow some time, because each ContinuationTask create new tasks. So its a never-ending recursion. But in fact it doesn t need to be a recursion, because i dont wait on a return value. I did not figure out yet, how to program my scenario.

I thought about hanging all child tasks to the same continuation task. But then i get a race condition with "set_ref_count". And when i try a mutex in it, it doesn t work either.

any ideas?

[Alexey-Kukanov]

Make the constructor of tasks as lightweight as possible, and do not bother with task reuse. If you need the data to be persistent between stages, decouple itfrom the tasks.

[zweistein]

I dont understand.

[Alexey-Kukanov]

Well, I don't know what you don't understand.
Don't try reusing the task objects; create a new one when you need it. The corpses of former tasks are kept in a pool in TBB, so the overhead to get a new one is low. Make the overhead of task object constructor low as well. If you need some data to persist between program stages, don't make these data part of a task; instead, keep it separately and make tasks reference it.

[zweistein]

ok, i understand thank you. That sounds good. But i still go into a stack overflow or not? I implemented something now and its fast. but my memory is going higher and higher. I think because some continuation tasks start new continuation tasks in an endless recursion without the chance that they ever get freed.

[jimdempseyatthecove]

Why not configure your one time "recursion" like a simulation system? Pseudo code:

BuildInitialTaskList();
while(!done)
{
InitializeNextTaskList();
ForEachTaskInCurrentTaskList
EnqueueTask();
SwapTaskLists();
}
...
YourLastTask()
{
...
BuildNextTaskList();
}

Something like that
IOW remove the recursion by moving the task enqueue responsibility back up the task stack.

Jim Dempsey

[zweistein]

Hi,

Yeah thats a good idea, too. But for the other things i will add, i better need the recursion thing.

I ve implemented it, but i still get memory leaks:

task* execute()

{

m_work->run();

if (condition)

{

tbb::task_list Tasks;

for (int i=0; i

{

TaskItem& tmp = *new( tbb::task::allocate_root() ) TaskItem( m_Fibs );

Tasks.push_back(tmp);

}

tbb::task::spawn( Tasks );

Tasks.clear();

return NULL;

}

}

crazy thing is that TaskItem gets allocated and destroyed. what can be wrong?

[zweistein]

Hey,

You see the variable tt? It manages the count of how many new tasks get spawned. I realized, that i get memory leaks as soon as tt is >64. When i spawn <= 64 new tasks i dont get memory leaks.

[zweistein]

for()

{

TaskItem& tmp = *new( tbb::task::allocate_root() ) TaskItem( m_Fibs );

tbb::task::spawn( tmp );

}

This does work without memory leak. I think something is wrong with task_list.

[Andrey_Marochko]

It's an interesting observation. We'll check it over.