分析 Linux 中的同步操作
我想分析同步操作，例如 Linux 中互斥锁、信号量等的锁定和解锁。
我知道在内心深处它们是使用 futexes 实现的，所以也许分析 futexes 的锁定和解锁就足够了（如果我错了，请纠正我）。所以我的问题是如何分析它，因为 futex 操作通常发生在用户空间中。他们有任何工具可以让我对此进行分析吗？
我基本上有兴趣了解锁定 futexes 和频率的函数。
I want to profile synchronization operations, such as locking and unlocking of mutexes, semaphores etc. in Linux.
I know that deep down they are implemented using futexes, so maybe it is enough to profile locking and unlocking of futexes (please correct me if I'm wrong here). So my question is how to profile it, since futex operations normally occur in user space. Is their any tool which allow me to profile this?
I am basically interested in knowing the functions which lock the futexes and the frequency.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能对 valgrind 及其工具 callgrind 感兴趣。
它将在文件中生成详细的调用图，其中包括每个函数中传递的时间量。
然后您可以使用 kcachegrind 查看所有这些，这是一个很好的可视化数据的 UI。
它将允许您查看所有调用 pthread_mutex_lock() （或其他）的函数，其中，按时间百分比排列的最重要的函数，...
callgrind 最相关的部分是您可以轻松找到单线程中的瓶颈线程程序，因为你只需要查看占用最多 cpu 时间的函数。
在多线程程序中，函数长时间等待某些东西（互斥体）是正常情况，因此比较困难。
您还可以使用 valgrind 的 Helgrind 工具，它有助于查找互斥体使用中的错误（潜在的死锁或潜在的数据争用）。
我猜它会分析您对同步函数的调用以及您读/写的数据，通过分析 可序列化 同步和数据访问的一致性。 （我重复一遍：我猜）。
valgrind 的核心功能：检查内存泄漏：
You could be interested by valgrind and it's tool callgrind.
It will generates a detailled callgraph into a file, with among others, the amount of time passed in each function.
Then you can see all of that with kcachegrind, which is a nice UI to visualize the data.
It will allow you to see all functions which called pthread_mutex_lock() (or others), and among them, the top ones, by percent of time, ...
The most relevant part of callgrind is that you can easily find bottleneck in single-threaded program, because you just have to look the function which took the most cpu time.
On multithreaded program, a function waiting a long time for something (a mutex) is a normal condition, so it's more difficult.
You can also use the tool Helgrind from valgrind, which help find errors in your usage of mutexes (potential deadlocks or potential data races).
I guess that it analyses your calls to synchronization functions, and the data you read/write, to detect potential problem (problem that could occur 1 time over 1000000), by analyzing the Serializability conformance of your synchronization and data access. (I repeat : I guess).
And the core feature of valgrind: Checking memory leak: