Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Work isolation to prevent deadlock

Gerveshi__Alex
Beginner
436 Views

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?

0 Kudos
3 Replies
Nikita_P_Intel
Employee
436 Views

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

0 Kudos
Gerveshi__Alex
Beginner
436 Views

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

0 Kudos
Nikita_P_Intel
Employee
436 Views

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

0 Kudos
Reply