Community
cancel
Showing results for 
Search instead for 
Did you mean: 
zweistein
Beginner
65 Views

Task Scheduler

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
0 Kudos
12 Replies
zweistein
Beginner
65 Views

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
Valued Contributor I
65 Views

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

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_K_Intel3
Employee
65 Views

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
Beginner
65 Views

I dont understand.
Alexey_K_Intel3
Employee
65 Views

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
Beginner
65 Views

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
Black Belt
65 Views

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
Beginner
65 Views

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
Beginner
65 Views

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
Beginner
65 Views

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
New Contributor III
65 Views

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