Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Nested parallel_for with mutex hangs


I have a set of data blocks that I process using a parallel_for loop. These data blocks are held in a pool that may be compressed. The first thread to access a block that is in the compressed pool triggers an uncompress routine.Now, I have a mutex that ensures that the uncompress routine is only executed by one task thread. But the uncompress routine uses its own parallel_for loop to speed up the decompression. When the inner parallel_for loop ends, control doesn't go back to the parent task that started the uncompress routine. Instead, it goes to starting one of the upper level parallel_for loop tasks (I've seen this on the stack when running in debug mode). That task then runs into the mutex that hasn't been unlocked yet, and -- depending on the type of mutex I use -- either deadlocks or crashes.

I've been able to fix this problem by adding the following line:

    tbb::task_scheduler_init init(GetNumberOfProcessors()+1);

In other words, give it one extra thread to use (beyond the default number) and control returns to the task doing the uncompress, as I expected it to do in the first place (and as the Microsoft parallel_for library does). But is there a better way to fix this issue?


0 Kudos
2 Replies

Short answer: you can try to use task isolation(doc) forum 

Additional information: [1] 


Thanks, that sounds exactly like what I was looking for. I'll give it a try.