相关疑难解决方法(0)

我已经在这个工作了几天 -

作为背景,我正在研究一个单线程C程序并使其成为多线程.我最近发现了一个新的死锁情况,但是当我看到gdb中的互斥锁时,我看到了

__lock = 2但是__owner = 0

这不是递归互斥锁.有没有人见过这个？我正在处理的程序是一个守护程序,这种情况只发生在以高吞吐率执行超过20分钟(大约)然后放松负载之后.如果您有任何想法,我将不胜感激.

编辑 - 我忽略了提及我的所有其他线程此时都处于空闲状态.

干杯

我试图让gdb/lldb存根为我正在制作的程序工作,现在它似乎使调试器死锁,所以我(讽刺地)在我的机器上调试lldb以试图找出出错的地方.

lldb试图锁定一个互斥锁,似乎就此陷入僵局.

在Windows上,我知道你可以在内核调试模式中使用WinDBG魔术来找出谁首先获得了互斥锁,而在Linux上我知道这pthread_mutex_t不是不透明的,你可以用它来弄清楚哪个线程非常简单.

Mac OS X怎么样？如果我想知道哪个线程拥有互斥锁,我该怎么办？

为了记录,我尝试在opensource.apple.com上搜索互斥结构的实际定义,没有太多运气,但这并不意味着它不存在.

我怎样才能看到（在linux上）哪些线程拥有pthread_rwlock_t（或std::shared_mutex）？

对于常规互斥体，是否可以确定持有互斥体的线程？但如何对 ar/w 锁执行此操作？

我的所有线程都卡在一个点上，此时的跟踪如下：

(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 …