Linux threading performance is very fast under GDB, but very slow in other cases

Linux threading performance is very fast under GDB, but very slow in other cases … here is a solution to the problem.

Linux threading performance is very fast under GDB, but very slow in other cases

I’m working on an embedded C++ application running on Linux. I’ve recently had some really weird pthreads performance issues.

My system has 8 threads passing information back and forth, protected by pthread mutexes. When running my application independently, thread performance is very slow when acquiring mutexes. It takes 2.4 seconds to lock and unlock the mutex about 200 times on a 500 MHz ARM board, and longer on my 200MHz board.

Strangely, when I run my application under GDB, the application runs very fast. When GDB runs, it takes about 2 milliseconds for the same block of code to run independently for 2.4 seconds.

I’ve tested this behavior on 2 different ARM-based SBCs: one running Linux 2.4.26, gcc 3.4.4, and glibc 2.3.2,

and the other running Linux 2.6.21, gcc 3.4.4, and glibc 2.3.2

After a lot of testing, I suspect the problem is with the pthreads library, which happens to be the same version on both board toolchains. This would be unfortunate because my SBC vendor doesn’t offer a wide variety of toolchains for their boards, and I’m afraid they’ll all run into this issue. Does anyone understand what might be causing poor performance when not running under GDB?

Solution

There has never been a problem with pthreads on ARM, and I suspect there are races or initialization issues in your code. Try to reduce your code to the minimum code that reproduces the issue.
You should post this code here, or the part you think is relevant.

Don’t forget select isn’t broken

Are you using LinuxThreads or NPTL (“kernel” threads?). )
If you are using the latter, you can also try tracking your app.

Related Problems and Solutions