C++ 螺纹卡在点“处的螺纹很少”；在“所有锁定等待”中；

我所有的线程都卡在一个点上，这一点的轨迹如下：

(gdb) info threads
  9 Thread 0x7fa872994700 (LWP 10301)  0x000000327b60e264 in __lll_lock_wait () from /lib64/libpthread.so.0
  8 Thread 0x7fa87379c700 (LWP 10302)  0x000000327b2accdd in nanosleep () from /lib64/libc.so.6
  7 Thread 0x7fa871b7c700 (LWP 10303)  0x000000327b2db74d in read () from /lib64/libc.so.6
  6 Thread 0x7fa87117b700 (LWP 10306)  0x000000327b60e264 in __lll_lock_wait () from /lib64/libpthread.so.0
  5 Thread 0x7fa864e14700 (LWP 10307)  0x000000327b60e264 in __lll_lock_wait () from /lib64/libpthread.so.0
  4 Thread 0x7fa85ffff700 (LWP 10308)  0x000000327b2db7ad in write () from /lib64/libc.so.6
  3 Thread 0x7fa85f5fe700 (LWP 10309)  0x000000327b60e264 in __lll_lock_wait () from /lib64/libpthread.so.0
  2 Thread 0x7fa85ebfd700 (LWP 10311)  0x000000327b2accdd in nanosleep () from /lib64/libc.so.6
* 1 Thread 0x7fa87379e720 (LWP 10300)  0x000000327b60822d in pthread_join () from /lib64/libpthread.so.0

我试图找出这是否与我的代码或系统配置的任何问题有关。 它正在所有其他机器上工作。 该问题仅在每次运行时发生在一台机器上。此机器的配置详细信息如下：

bash-4.1$cat/etc/redhat版本 Red Hat Enterprise Linux Server 6.5版（圣地亚哥）

bash-4.1美元联阿援助团-a Linux localhost 2.6.32-431.el6.x86#u 64#1 SMP Sun 11月10日22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

bash-4.1$rpm-qa | grep glibc glibc-devel-2.12-1.132.el6.x86_64 glibc-2.12-1.132.el6.x86_64 glibc-common-2.12-1.132.el6.x86_64 glibc-headers-2.12-1.132.el6.x86_64

以下是螺纹未卡住（工作正常）的机器配置，仅供参考：

---

正如这个答案中所建议的，查看每个等待回溯的线程

(gdb) thr 9
(gdb) bt

#0  0x00007f5e45c553dd in __lll_lock_wait () at /lib64/libpthread.so.0
#1  0x00007f5e45c4e7d4 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2  0x00007f5e458cc84f in gst_element_set_state_func (element=0x7f5d94461ca0, state=GST_STATE_READY) at gstelement.c:2831

转到锁定互斥锁的堆栈帧，并查看互斥锁以获取锁柜的线程id

(gdb) f 2  # look frame 2, as an example
#2  0x00007f5e458cc84f in gst_element_set_state_func (element=0x7f5d94461ca0, state=GST_STATE_READY)
    at gstelement.c:2831
2831      GST_STATE_LOCK (element);

找到试图锁定的互斥体的符号，并打印其内容

(gdb) p element.state_lock
$3 = {p = 0x7f5d0c03f2a0, i = {0, 0}}

(gdb) p *(struct __pthread_mutex_s *)element.state_lock.p
$6 = {__lock = 2, __count = 1, __owner = 11889, __nusers = 1, __kind = 1, __spins = 0, __elision = 0, 
  __list = {__prev = 0x0, __next = 0x0}}

如果没有符号但有地址，可以通过检查内存将其打印出来

(gdb) x/4x 0x7f5d0c03f2a0   # address of the mutex
0x7f5d0c03f2a0: 0x00000002      0x00000001      0x00002e71      0x00000001
(gdb) p 0x2e71
$7 = 11889

在当前版本的linux pthreads上，所有者位于第三个值中。如上问题LWP#10311中所述，查看线程2并了解其被阻止的原因。 或者在本例中，LWP#11889，螺纹18

(gdb) info thr
[ ... ]
  18   Thread 0x7f5dc9dff700 (LWP 11889) "task114"        0x00007f5e45c5203c in pthread_cond_wait@@GLIBC_2.3.2

(gdb) thr 18
(gdb) bt
#0  0x00007f5e45c5203c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
[ ... ]

---

在

读取

和

写入

中有一个线程，这些线程也被卡住了吗？一般来说，如果遇到这样的错误，它不太可能是当前在数百万台机器上运行的系统库中的错误，也很可能是自己代码中的错误。

\uull\u lock\u wait（）

通常是因为您试图锁定已被另一个线程锁定的互斥锁-因此，如果它在其他机器上工作，它看起来有点像导致死锁的竞争条件。不过，您的glibc看起来很旧（当前版本为2.24），所以如果您正在使用例如优先级继承互斥体之类的高级功能，那么您可能也遇到了某种错误（我有一个问题：）。试试看你是否能找出问题并做一个小测试用例？@Karsten Koop，是的，两个线程都卡住了。你试过使用吗？

(gdb) info thr
[ ... ]
  18   Thread 0x7f5dc9dff700 (LWP 11889) "task114"        0x00007f5e45c5203c in pthread_cond_wait@@GLIBC_2.3.2

(gdb) thr 18
(gdb) bt
#0  0x00007f5e45c5203c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
[ ... ]