持有 boost::interprocess::scoped_lock 时休眠会导致它永远不会被释放

Question

我正在 Linux 上使用 boost::interprocess::shared_memory_object 按照 参考（匿名互斥示例）。

有一个服务器进程，它创建 shared_memory_object 并写入它，同时持有包装在 scoped_lock 中的 interprocess_mutex； 一个客户端进程打印其他进程写入的内容 - 在本例中，它是一个 int。

我遇到了一个问题：如果服务器在持有互斥体时休眠，则客户端进程永远无法获取它并永远等待。

Buggy server 循环：

using namespace boost::interprocess;
int n = 0;
while (1) {
    std::cerr << "acquiring mutex... ";
    {
        // "data" is a struct on the shared mem. and contains a mutex and an int
        scoped_lock<interprocess_mutex> lock(data->mutex);
        data->a = n++;
        std::cerr << n << std::endl;
        sleep(1);
    } // if this bracket is placed before "sleep", everything works
}

Server 输出：

acquiring mutex... 1
acquiring mutex... 2
acquiring mutex... 3
acquiring mutex... 4

Client 循环：

while(1) {
   std::cerr << "acquiring mutex... ";
   {
      scoped_lock<interprocess_mutex> lock(data->mutex);
      std::cerr << data->a << std::endl;
   }
   sleep(1);
}

Client 输出（永远等待）：

acquiring mutex...

问题是，如果我将括号移至 sleep 调用之前的行，一切正常。 为什么？ 我不认为与锁定的互斥体一起睡觉会导致互斥体永远被锁定。

我唯一的理论是，当内核唤醒服务器进程时，作用域结束并且互斥锁被释放，但是等待进程没有机会运行。 然后服务器重新获取锁...但这似乎没有多大意义。

谢谢！

Answer 1

持有互斥体时睡觉是错误的。 互斥体保护一些数据（即数据->a），并且应该最小化该数据的读/写范围。

Answer 2

你的理论是正确的。

如果您查看链接的参考文献中匿名互斥示例的底部，您将看到

正如我们所见，互斥锁对于保护数据很有用，但对于向另一个进程通知事件却没有用。

释放互斥体不会通知任何可能正在等待它的其他人，并且由于您的进程刚刚醒来，因此几乎可以肯定它还有大量的调度时间来完成更多工作。 它将循环并在再次休眠之前重新获取互斥锁，这是客户端第一次有机会获取互斥锁本身。

将服务器 sleep() 移出作用域意味着它会在互斥体空闲时进入睡眠状态，从而使客户端有机会运行并为自己获取互斥体。

如果您想放弃处理器，但仍然在您的范围内休眠，请尝试调用 sched_yield()（仅限 Linux）。 sleep(0) 也可能有效。