- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm running into a similar problem as described here
I have a task that calls into a 3rd party library, and based on the result, my task can create child tasks of the same type.
This 3rd party library also uses tbb, but is not written with the expectation that the library itself would be called from within a TBB task.
MyTbbTask::execute() { result = third_party_lib::getResult(this->getArgs()); // process result // create and spawn child MyTbbTask instances }
third_party_lib::getResult(Args a) { // get read lock on private static rw-mutex if (isCached(a)) { return getCached(a); } // upgrade lock to write lock // potentially execute multiple nested calls to spawn_root_and_wait() return loadResult(a); }
If a pending outer-level MyTbbTask is executed due to task stealing in one of the calls to spawn_root_and_wait(), I get a deadlock on the mutex in getResult().
I tried calling getResult() inside of a task_arena, but in the case where the calling thread can't enter the arena and instead creates a task and waits for it, the deadlock can still occur.
Is there a way to always execute getResult() on the calling thread while still isolating any tasks that it creates from outer-level tasks?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Alex,
You can call getResult() from an isolated region via Task Isolation feature to prevent the current thread from taking tasks related to the outer execution level.
Thanks, Nikita
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Nikita,
Thanks for responding.
I had looked at that page previously, and it seems like task_arena would solve my problem if there were a way to guarantee that the calling thread is allowed to enter the arena and execute the function, rather than there also being the possibility that the function is wrapped in a task and executed by a thread already in the task_arena.
this_task_arena::isolate seems to only isolate the current thread from executing outer level tasks, but not other threads that may execute child tasks. Is that correct?
-Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is correct. Current thread will acquire the lock and start to execute child task, in the worst case all other threads will wait on this lock and can't be involved in child tasks processing. Isolation solves correctness issue, but due to the common thread pool and your locks, performance issue remains.
- Nikita
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page