task_arena uses

[e4lam]

Is there blog post or other information regarding the new task_arena class currently in the community preview? I've read the docs on this but still unsure of the use cases surrounding it.

We've encountered serious problems in using legacy code with TBB. Say we have some tasks spawned which call function A(). A() locks a shared resource and then calls into other code that spawns more tasks. Due to the task stealing nature of TBB's scheduler, the worker thread that has A() on its stack may steal a task that runs A(). This causes a deadlock because A() has not finished yet, and can't because it is stuck earlier in the stack. (I think an example of this was discussed by Arch Robison in an old forum thread, except that the "graph" ends up occuring implicitly through natural code execution.)

I wonder if task_arena might be employed to solve the above scenario. So when a resource is locked, we start all nested subtasks into a new task_arena. So in this way, we "protect" the the current worker thread that owns the lock from stealing tasks that may try to acquire the same lock. Rewriting the code to avoid this scenario is often very hard in legacy code since these situations are spread out over several generic libraries that depend on each other. It would be nice if there was an easy way in TBB to handle these situations.

Thanks in advance!

-Edward

[RafSchietekat]

Also see "Inner parallelization calls outer".

[e4lam]

Thanks for pointing out at this other thread, Raf! I hope I'm clearer than the other poster though. :) I skimmed through it and it does seem that this discussion might have been the precursor to task_arena? I also went through the referenced blog entry and it seems to confirm that task stealing should be restricted across different arena's.

It's quite a long thread though and I'm not sure I followed all the details. Since you were intimately involved in the discussion, care for a summary? :) Do you think this issue should be be solvable as I described above?

Thanks!

[RafSchietekat]

The arena already existed, and is now being given more visibility, but the discussion I referenced was only incidental to that (if that's the right word). If you only read the later postings, you probably won't have missed too much; you can probably skip my earlier postings in particular, because I got off to a slow start there...

[e4lam]

Upon close reading of the blog and documentation, I don't think task_arena actually has any isolation of tasks to be run between different threads because the workers dynamically migrate amongst different arenas. So it's unsuitable for solving the problem at hand.

[RafSchietekat]

I was under the impression that this free migration was only for unencumbered threads, while those that had partly finished work on their stacks were restricted to steal only from their own arenas. Perhaps you should go over the documentation one more time with that in mind? If it is not clear, it's worthwhile to point that out so the text can be improved.

(Added) Of course that doesn't mean that arenas will do the job (yet), but that's for other reasons.