Work isolation to prevent deadlock

Work isolation to prevent deadlock

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.

    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?

publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

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

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?


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

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya