GDB下的Linux线程性能非常快，但速度极慢

Question

我正在研究在Linux上运行的嵌入式C ++应用程序。我最近遇到了一些非常奇怪的pthreads性能问题。

我的系统有8个线程使用pthread互斥锁来保护来回传递信息。当独立运行我的应用程序时，在使用互斥锁时线程性能非常慢。锁定和解锁互斥锁〜200次在500 MHz ARM板上需要2.4秒，在200MHz主板上需要更长时间。

奇怪的是，当我在GDB下运行我的应用程序时，应用程序运行得非常快。当GDB运行时，相同的代码块需要2.4秒独立需要大约2ms。

我在2个不同的基于ARM的SBC上测试了这种行为：一个运行Linux 2.4.26，gcc 3.4.4和glibc 2.3.2，另一个运行Linux 2.6.21，也运行gcc 3.4.4和glibc 2.3.2。

经过大量测试后，我怀疑问题出在pthreads库中，两个板的工具链上的版本恰好相同。这很不幸，因为我的SBC供应商没有为他们的主板提供各种各样的工具链，我担心他们都会遇到这个问题。有没有人知道在不在GDB下运行时可能导致性能不佳的原因？

Answer 1

从未遇到过ARM上的pthread问题，我怀疑代码中存在竞争或初始化问题。尝试将代码减少到重现问题的最小代码。 您应该在此处发布此代码，或者您认为相关的部分。

通常不要忘记select isn't broken

您使用的是LinuxThreads还是NPTL（“内核”线程？） 如果您使用后者，您也可以尝试使用它。

Answer 2

您可以看到的一个想法是旋转计数值。这在ARM而不是Intel系统上肯定是不同的。

您可以尝试使用“pthread_mutex_trylock（）”然后执行显式“sched_yield（）”，如果它无法获取锁定，可能会在循环内添加毫秒睡眠。通过这种方法，您可以打破锁定操作并查看锁定是否存在争用。

我敢打赌你需要查看源代码或至少反汇编的“pthread_mutex_lock”来修复它。

Answer 3

您确定以您认为的方式初始化互斥锁吗？这个东西是在文件范围变量中还是已分配？我认为由于内存初始化绘制的好运，gdb最终会在互斥锁上给你一组不同的选项。