parallel execution in TBB freezes

Question

So here's the problem. I have a piece of code that when execute in only one thread, it works perfectly. But once this code is called with TBB, it froze (or I just don't have the patience to wait it finishes!).

The code is too long, but imagine this:

class TBB_Test
{
public:
  TBB_Test(void) { /* initialize the stuff */ }

  void operator() (tbb::blocked_range<int> &r) const
  {
    for (int i = r.begin(); i != r.end(); ++i)
    {
      // compute very awesome stuff!
    }
  }
};

So, when I execute it in sequential:

TBB_Test() (tbb::blocked_range<int>(0, max_value));

it works, but once in parallel:

tbb::parallel_for(tbb::blocked_range<int>(0, max_value, grainsize), TBB_Test());

it froze instead of being faster than the sequential one.

What could cause such a thing ? Two threads trying to read or write at the same place ? In our case, writing shouldn't not happen! And we have other situation where the same address is probably read by multiple threads and it doesn't freeze!

Any idea?

In VStudio, at least there, when debugging, just activate so the debugger stops at all kind of exceptions... long, but the right way to do it!

PS: Have you stepped through any of this under the debugger? When it "freezes", is it in an infinite loop? Blocked? Deadlocked? Are there any globals the your threads might be stepping on? Etc etc — paulsm4, Jul 31 '12 at 17:39
the default debugger in VS doesn't seam to catch anything wrong... and trying to step through it in parallel, don't know how! I isolated the problem to a single function call now. Still analysing... but hoping to learn more trick too with TBB! So, if you solved a similar problem once by checking a particular thing, it might be helpful! — widgg, Jul 31 '12 at 17:46
Apparently... in parallel, there's an exception that is thrown and because there's no try/catch in the parallel code itself, it goes out and got lost probably! So, TBB doesn't seam to be exception proof. — widgg, Jul 31 '12 at 17:58
Okay... after hours of painful analysis, we found the source of the problem. Part of the code totally not thread safe like memory allocation! But hey, thanks for your participation ;) — widgg, Jul 31 '12 at 18:19
It would be good if you answered your own question to explain what was wrong and how you found and fixed it. That way, you might help somebody who has a similar problem, and possibly get some upvotes too. — Alexey Kukanov, Aug 04 '12 at 18:08
It's not fixed... we just ignore it for now! that's a bit sad, but we don't have the time to solve this now! — widgg, Aug 07 '12 at 18:10

score 0 · Accepted Answer · answered Sep 04 '12 at 14:13

So naturally, it was a memory allocation problem.

The bad solution is to use mutex where the memory is allocated. This is bad because you end up with your X processors running to the max... mostly waiting on mutex.

The final approach that we used is that each slice had its one memory allocation scheme. Then, by using a "join", we merge the data together after it was computed. So this way the processor are running without any mutex. But this cause way more memory to be required. But as along as there's no duplication between threads, you should be fine!

So, lesson learned!

parallel execution in TBB freezes

1 Answers1