代码之家  ›  专栏  ›  技术社区  ›  Jason Machacek

在gdb下Linux线程性能非常快,但在其他情况下非常慢

  •  3
  • Jason Machacek  · 技术社区  · 15 年前

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

    我的系统有8个线程通过pthread互斥锁来回传递信息。当独立运行我的应用程序时,线程性能在获取互斥锁时非常缓慢。锁定和解锁互斥约200次需要2.4秒,在500兆赫的臂板上,在200兆赫的板上需要更长的时间。

    奇怪的是,当我在gdb下运行应用程序时,应用程序运行得非常快。当gdb运行时,同样的代码块需要2.4秒的独立运行时间,大约需要2毫秒。

    我在两个不同的基于ARM的SBC上测试了这种行为:一个运行带有GCC 3.4.4和glibc 2.3.2的Linux2.4.26,另一个运行带有GCC 3.4.4和glibc 2.3.2的Linux2.6.21。

    经过广泛的测试,我怀疑问题出在pthreads库中,这个库恰好是两个板的工具链上的相同版本。这将是不幸的,因为我的SBC供应商没有为他们的董事会提供非常广泛的工具链,我担心他们都会有这个问题。当不在gdb下运行时,有人知道什么会导致性能低下吗?

    3 回复  |  直到 15 年前
        1
  •  3
  •   shodanex    15 年前

    手臂上的pthreads从来没有问题,我怀疑您的代码中存在种族或初始化问题。尽量将代码减少到最少,以重现问题。 您应该在这里发布这个代码,或者您认为相关的部分。

    别忘了,通常, select isn't broken

    您使用的是linuxthreads还是nptl(“内核”线程?) 如果您正在使用后者,您也可以尝试删除您的应用程序。

        2
  •  1
  •   Lothar    15 年前

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

    您可以尝试使用“pthread_mutex_try lock()”,然后执行显式的“sched_yield()”,如果它不能获取锁,那么可以在循环中添加毫秒睡眠。通过这种方法,您可以中断锁操作,并查看锁上是否存在争用。

    我敢打赌,您需要查看源代码,或者至少查看反汇编的“pthread-mutex-lock”来修复它。

        3
  •  0
  •   bmargulies    15 年前

    您确定要按照您认为的方式初始化互斥体吗?这是在文件范围变量中还是在分配中?我在想,由于内存初始化绘制的运气,gdb最终会在互斥体上为您提供一组不同的选项。