Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Task Scheduler

zweistein
Beginner
248 Views
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
248 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
248 Views
check out:
tbb/examples/task/tree_sum/OptimizedParallelSumTree.cpp
and in particular, recycle_as_continuation().
zweistein
Beginner
248 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
248 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
248 Views
I dont understand.
Alexey_K_Intel3
Employee
248 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
248 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
248 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
248 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
248 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
248 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
248 Views
It's an interesting observation. We'll check it over.
Reply