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?
