提升 scoped_lock 导致 CPU 消耗过多

Posted 2023-02-21

【中文标题】提升 scoped_lock 导致 CPU 消耗过多

【英文标题】：Too much CPU consumption by boost scoped_lock

【发布时间】：2011-10-26 11:00:30

【问题描述】：

我有一些代码等待共享内存上的写操作。 如果没有人写，它会继续等待。

    Test* Foo::Get() 
    
        boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> lock ( mutex ) ; // mutex is boost::interprocess::interprocess_mutex
        if ( this->check == 0 )
            this->interprocessCondition.wait ( lock ) ; // interprocessCondition is boost::interprocess::interprocess_condition

...
    

当我进行采样时，我发现它消耗了大约 90% 的 CPU。

谁能帮我解决这个性能问题？请看附图。

【问题讨论】：

您是在做其他事情还是只是在分析锁？ “其他”代码是什么样的？

它只是从其他的共享内存中读取。我分析了完整的可执行文件。

这没有多大帮助。与从共享内存中读取 int 相比，获取锁占用的 CPU 多 很多 是正常的。你可以通过减少锁的细粒度来解决它。

更多调试指向inline void sched_yield()，对于 Windows，它调用 Sleep(1)，但我找不到 Mac 的任何定义？

90% CPU 是什么意思？它会在一段时间内创建一个繁忙的循环，还是实际上让给另一个进程？

【参考方案1】：

boost::interprocess，不幸的是，在许多平台（显然包括 OSX）上使用忙等待锁。您将需要使用您的平台本机的锁，该锁实际上处于休眠状态。

【讨论】：

或者幸运的是，这取决于你想要达到的目标。

我添加了 sleep(1) 代替 sched_yield();称呼？现在它非常漂亮。除了我必须注意提升更新而不干扰代码之外，它会不会有任何副作用？

@MacGeek，这会大大增加唤醒延迟

但是，Boost 在 Windows 上使用 sleep(1) 吗？效果不应该一样吗？

@MacGeek，在 OS X 上，sleep(1) 等待一秒钟。在 Windows 上，Sleep(1) 等待一 毫秒。