- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
12 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
check out:
tbb/examples/task/tree_sum/OptimizedParallelSumTree.cpp
and in particular, recycle_as_continuation().
tbb/examples/task/tree_sum/OptimizedParallelSumTree.cpp
and in particular, recycle_as_continuation().
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I dont understand.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's an interesting observation. We'll check it over.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page