问题标签 [futex]

A Python process hangs in futex():

I want to see the stacktrace if the hanging process.

Unfortunately ctrl-c does not work :-(

How can I see the stacktrace if Python hangs like this?

I've written a small Go library (go-patan) that collects a running min/max/avg/stddev of certain variables. I compared it to an equivalent Java implementation (patan), and to my surprise the Java implementation is much faster. I would like to understand why.

The library basically consists of a simple data store with a lock that serializes reads and writes. This is a snippet of the code:

I've benchmarked the GO and Java implementations (go-benchmark-gist, java-benchmark-gist) and Java wins by far, but I don't understand why:

I've profiled the program with the Go's pprof and generated a call graph call-graph. This shows that it basically spends all the time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock().

The Top20 calls according to the profiler:

Can someone explain why locking in Go seems to be so much slower than in Java, what am I doing wrong? I've also written a channel based implementation in Go, but that is even slower.

运行包含并行 OpenMP 区域的 Fortran 代码时，我遇到了一个问题，即在代码运行良好一段时间后（下面代码中的 counter=~1,000,000,000），它停止运行而不会崩溃或提供任何错误。重现该问题的代码片段是：

当我这样做时strace -p PID，使用此代码生成的进程（16 个核心）的 PI​​D，其中一个会产生：

一遍又一遍，即使在其他进程停止做任何事情之后。在不同的机器上运行相同的代码，上面的 strace 输出没有出现，代码运行正常。串行运行代码，它在两台机器上运行良好。

我在两台机器上使用 ifort (v 15.0.2) 和 gfortran (v 4.8.5) 编译，结果相同：一台机器工作，另一台机器做疯狂的事情。

我发现一些信息表明这可能是 linux 内核的问题。产生错误的机器有“Linux 2.6.32-431.23.3.el6.x86_64”另一个“Linux 3.10.0-327.18.2.el7.x86_64”。有谁知道如何解决/解决这个问题？

同一进程中的两个线程使用存储在共享内存中的 rwlock 对象在 pthreads 压力测试期间遇到崩溃。我花了一段时间试图找到内存损坏或死锁，但到目前为止还没有。这只是一种不太理想的方式来通知我我已经造成了僵局吗？关于调试这个的工具/方法的任何指针？

我在 linux 系统（Redhat 6.6）上使用 java 应用程序。有时，此应用程序会收取 100% 的 CPU 费用。

这是proc strace。

strace印刷"futex .. ETIMEOUT"。所以我猜是“闰秒错误”。

我想解决这个问题。但问题机器无法访问某些原因。

所以我必须在其他系统（linux）上重现这种情况。

我怎样才能重现这种情况？

系统信息

• 操作系统：Linux 2.6.32-504.el6.x86_64 (amd64)

• 红帽企业 Linux 服务器 6.6 版（圣地亚哥）

在futexLinux 中存在系统调用之前，线程库使用了哪些底层系统调用pthreads来阻塞/休眠线程并随后从用户空间唤醒这些线程？

例如，如果一个线程试图获取一个互斥锁，用户态实现将阻塞该线程（可能在短暂的旋转间隔之后），但我找不到用于此的系统调用（除了futex相对较新的创建）。

我有一个简单的 Monte-Carlo Pi 计算程序。我尝试在 2 个不同的机器上运行它（相同的硬件，内核版本略有不同）。我在一个案例中看到了显着的性能下降（两次）。没有线程，性能基本相同。程序的分析执行表明，较慢的程序在每次 futex 调用上花费的时间较少。

• 这与任何内核参数有关吗？
• CPU 标志会影响 futex 性能吗？/proc/cpuinfo 表示 cpu 标志略有不同。
• 这是否与python版本有关？

Linux(3.10.0-123.20.1 (Red Hat 4.4.7-16)) Python 2.6.6

Linux(3.10.0-514.26.2 (Red Hat 4.8.5-11)) Python 2.7.5

测试程序

我已经将 pthread 用于多线程程序，并且遇到以下情况。当我在没有 sleep 命令的情况下运行代码时，它会在运行时导致错误，并且当我添加 sleep 命令时，程序会按预期运行。

与睡眠：

不睡觉：

错误：

futex(0x559c3d3df0a0, FUTEX_WAIT_PRIVATE, 2, NULLHello ) = -1 EAGAIN (资源暂时不可用)

您将不得不原谅相当大的代码块，但我相信这几乎是对我的问题的最小再现。该问题并非孤立存在，example.com而是存在于许多其他站点中。

如果我有 4 个线程主动发出网络请求，curl 可以 100% 正常工作。

如果我再添加一个线程，该线程的执行时间约为 10 倍。我觉得我一定遗漏了一些明显的东西，但它现在逃脱了我。

更新更多信息：这些测试在虚拟机中。与机器可用的内核数量无关，其中四个请求大约需要 100 毫秒，其余请求大约需要 5500 毫秒。

更新 2：实际上，我在一个方面是错误的，它并不总是4/n-4分布——当我更改为4内核时，有时我会得到不同的结果分布（在 1 个内核上运行至少看起来相对一致）——这是一个当线程在 4 核 VM 上运行时返回其延迟 (ms) 而不是其 http 代码时的结果片段：

更新3：我从头开始构建curl和openssl，删除了锁定（因为openssl 1.1.0g不需要它）并且问题仍然存在。（健全性检查/通过以下验证）：

输出：

示例延迟：

更新 4：设置CURLOPT_CONNECTTIMEOUT_MS等于对返回时间设置x了x上限。

更新 5，最重要的：

在 5 个线程下运行程序strace -T ./a.out 2>&1 | vim -，当程序只有 1 个慢请求时，产生了两条非常慢的行。这是对同一个 futex 的两次调用，一次比第二次花费了更长的时间，但都比所有其他 futex 调用都花费了更长的时间（大多数是 0.000011 毫秒，这两个调用需要 5.4 和 0.2 秒才能解锁）。

此外，我验证了缓慢完全在curl_easy_perform.

最后，在查看了源代码之后，我发现该错误在 DNS 查找中的某个地方。用 IP 地址替换主机名是解决问题的创可贴，无论它是什么地方。

------------

下面是我对该问题的最小复制/提炼，用 编译g++ -lpthread -lcurl -lcrypto main.cc，链接到从源代码构建的 openssl 和 libcurl 版本。

当我在我的机器上运行程序时，我得到以下结果（我可以将域更改为任何内容，结果是相同的）：

这是我的 curl 版本和 openssl 版本：

这个问题类似于How to call a function on a thread's creation and exit? 但更具体。在另一个多进程共享内存项目中，我使用了一个__attribute__((constructor))标记的库初始化例程、每个线程的延迟初始化和健壮的 futex的组合，以确保资源不会泄漏到共享内存中，即使是 sys管理员选择 SIGKILL 使用它的进程之一。然而，API 中的 futex 是一种方式对于我当前的项目来说，重量级太重了，甚至一些关于延迟初始化的指令都是我宁愿避免的。库 API 将在多个进程的数百个线程上被调用数万亿次（每个 API 只有几百条指令。）

我猜答案是否定的，但由于我花了几个小时寻找并没有找到明确的答案，我想我会在这里问它，那么下一个寻找简单答案的人将能够更快地找到它。

我的目标非常简单：在多个进程中异步创建线程时执行一些每个线程的初始化，并在线程被异步销毁时稳健地执行一些清理。不一定要立即发生，它必须最终发生。

进行批判性思维的一些假设想法：从 __attribute__((constructor)) 标记的库 init func 调用的假设 pthread_atclone() 将满足第一个条件。以及对 futex()es 的扩展，以添加具有每个线程 futex_adj 值的类 semop 操作，如果 do_exit() 中的值非零，则为 futex“信号量”设置 FUTEX_OWNER_DIED，从而允许在下一次清理futex 被触动了。