Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Dean_C_
Beginner
42 Views

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
Maksim_D_Intel
Employee
42 Views

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

Additional information: [1] 

Dean_C_
Beginner
42 Views

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

Reply