互斥睡眠占用了大量的CPU

Question

我用ruby-prof描述了我的基于事件机器的应用程序，发现了以下有趣的内容：

                  5.28    0.00    5.28    0.00          4/4     Mutex#synchronize
90.72%   0.00%    5.28    0.00    5.28    0.00            4     Mutex#sleep

我认为ruby-prof只计算CPU滴答，因此我无法弄清楚为什么互斥锁睡眠会占用CPU时间。我假设它在内核级别上休眠而不计算光纤时间。有任何想法吗？更好的是，我希望Mutex＃sleep能够释放对事件机器的控制权，所以它可以做其他事情。

Answer 1

如果ruby-prof --mode = cpu实际上只是占用CPU时间，那么Mutex #sleep是一个自旋锁：

http://en.wikipedia.org/wiki/Spinlock

这是有道理的，因为你只应该在互斥锁中包含非常短的赋值。设置信号警报将是一种疯狂的开销。

因此，您面临的挑战是确定您正在睡觉的互斥锁，以及它们包装的内容。然后，你要么发现可以避免的互斥，要么是不可避免的等待时间。

Answer 2

据我所知，如果您等待锁定释放，该线程将陷入睡眠模式。保持Eventmachine运行的唯一方法是确保锁定发生在一个单独的线程中。

Answer 3

90％可能意味着你90％的时间都在“睡觉”[？]一般情况下EM你不需要睡觉，你只是回应事件，而且大多数cpu会显示为EM的“运行”方法

Answer 4

通常，如果一个线程正在做某事而第二个线程正在等待它完成，那么它将被视为正在休眠。所以你的 sleep 时间可以是（取决于你的线程）： - 你的线程正在等待一个事件（空闲） - 你的那里正在等待另一个线程完成某事（其他线程忙）

Answer 5

这里提供准确答案的信息太少了，但是，我建议考虑其他几个方面，例如ruby-prof是否甚至花费在反应堆中的时间？

无视ruby-prof给你的百分比，你的个人资料实际运行了多长时间，以及实际花费在互斥锁上的时间有多长？它可能只显示#defer线程或类似的东西，完全忽略了另一个线程中的C ++运行时。