锁定 C++11 std::unique_lock 会导致死锁异常

Question

我正在尝试使用 C++11 std::condition_variable，但是当我尝试从第二个线程锁定与其关联的 unique_lock 时，我得到一个异常“避免资源死锁”。创建它的线程可以锁定和解锁它，但不是第二个线程，即使我很确定 unique_lock 不应该在第二个线程尝试锁定它时已经被锁定。

FWIW 我在 Linux 中使用 gcc 4.8.1 和 -std=gnu++11。

我已经围绕 condition_variable、unique_lock 和 mutex 编写了一个包装类，所以我的代码中没有其他任何东西可以直接访问它们。注意 std::defer_lock 的使用，我已经掉进了那个陷阱:-)。

class Cond {
private:
    std::condition_variable cCond;
    std::mutex cMutex;
    std::unique_lock<std::mutex> cULock;
public:
    Cond() : cULock(cMutex, std::defer_lock)
    {}

    void wait()
    {
        std::ostringstream id;
        id << std::this_thread::get_id();
        H_LOG_D("Cond %p waiting in thread %s", this, id.str().c_str());
        cCond.wait(cULock);
        H_LOG_D("Cond %p woke up in thread %s", this, id.str().c_str());
    }

    // Returns false on timeout
    bool waitTimeout(unsigned int ms)
    {
        std::ostringstream id;
        id << std::this_thread::get_id();
        H_LOG_D("Cond %p waiting (timed) in thread %s", this, id.str().c_str());
        bool result = cCond.wait_for(cULock, std::chrono::milliseconds(ms))
                == std::cv_status::no_timeout;
        H_LOG_D("Cond %p woke up in thread %s", this, id.str().c_str());
        return result;
    }

    void notify()
    {
        cCond.notify_one();
    }

    void notifyAll()
    {
        cCond.notify_all();
    }

    void lock()
    {
        std::ostringstream id;
        id << std::this_thread::get_id();
        H_LOG_D("Locking Cond %p in thread %s", this, id.str().c_str());
        cULock.lock();
    }

    void release()
    {
        std::ostringstream id;
        id << std::this_thread::get_id();
        H_LOG_D("Releasing Cond %p in thread %s", this, id.str().c_str());
        cULock.unlock();
    }
};

我的主线程创建了一个 RenderContext，它有一个与之关联的线程。从主线程的角度来看，它使用 Cond 向渲染线程发出信号以执行操作，并且还可以在 COnd 上等待渲染线程完成该操作。渲染线程在 Cond 上等待主线程发送渲染请求，并在必要时使用相同的 Cond 告诉主线程它已经完成了一个动作。当渲染线程尝试锁定 Cond 以检查/等待渲染请求时，会出现我遇到的错误，此时它根本不应该被锁定（因为主线程正在等待它），更不用说由相同的线程。这是输出：

DEBUG: Created window
DEBUG: OpenGL 3.0 Mesa 9.1.4, GLSL 1.30
DEBUG: setScreen locking from thread 140564696819520
DEBUG: Locking Cond 0x13ec1e0 in thread 140564696819520
DEBUG: Releasing Cond 0x13ec1e0 in thread 140564696819520
DEBUG: Entering GLFW main loop
DEBUG: requestRender locking from thread 140564696819520
DEBUG: Locking Cond 0x13ec1e0 in thread 140564696819520
DEBUG: requestRender waiting
DEBUG: Cond 0x13ec1e0 waiting in thread 140564696819520
DEBUG: Running thread 'RenderThread' with id 140564575180544
DEBUG: render thread::run locking from thread 140564575180544
DEBUG: Locking Cond 0x13ec1e0 in thread 140564575180544
terminate called after throwing an instance of 'std::system_error'
  what():  Resource deadlock avoided

说实话，我真的不明白 unique_lock 的用途以及为什么 condition_variable 需要一个而不是直接使用互斥锁，所以这可能是问题的原因。我在网上找不到很好的解释。

Answer 1

前言：了解条件变量的重要一点是，它们可能会受到随机、虚假的唤醒。换句话说，CV 可以从wait() 退出，而无需任何人先调用notify_*()。不幸的是，没有办法将这种虚假唤醒与合法唤醒区分开来，因此唯一的解决方案是拥有一个额外的资源（至少是一个布尔值），以便您可以判断唤醒条件是否实际满足。

这个额外的资源也应该由互斥体保护，通常与您用作 CV 伴侣的相同。

---

CV/mutex 对的典型用法如下：

std::mutex mutex;
std::condition_variable cv;
Resource resource;

void produce() {
    // note how the lock only protects the resource, not the notify() call
    // in practice this makes little difference, you just get to release the
    // lock a bit earlier which slightly improves concurrency
    {
        std::lock_guard<std::mutex> lock(mutex); // use the lightweight lock_guard
        make_ready(resource);
    }
    // the point is: notify_*() don't require a locked mutex
    cv.notify_one(); // or notify_all()
}

void consume() {
    std::unique_lock<std::mutex> lock(mutex);
    while (!is_ready(resource))
        cv.wait(lock);
    // note how the lock still protects the resource, in order to exclude other threads
    use(resource);
}

与您的代码相比，请注意多个线程如何同时调用produce()/consume() 而不必担心共享unique_lock：唯一共享的东西是mutex/cv/resource，每个线程都有自己的unique_lock，这迫使线程等待如果互斥锁已被其他东西锁定，则轮到它。

如您所见，资源并不能真正与 CV/互斥锁对分开，这就是为什么我在评论中说您的包装类并不真正适合恕我直言，因为它确实试图将它们分开。

通常的方法不是像您尝试的那样为 CV/mutex 对制作包装器，而是为整个 CV/mutex/resource 三重奏组制作包装器。例如。一个线程安全的消息队列，消费者线程将在 CV 上等待，直到队列有消息可供使用。

---

如果您真的只想包装 CV/互斥锁对，您应该摆脱不安全的 lock()/release() 方法（从 RAII 的角度来看）并将它们替换为单个lock() 方法返回 unique_ptr:

std::unique_ptr<std::mutex> lock() {
    return std::unique_ptr<std::mutex>(cMutex);
}

这样你就可以使用你的Cond包装类，就像我上面展示的一样：

Cond cond;
Resource resource;

void produce() {
    {
        auto lock = cond.lock();
        make_ready(resource);
    }
    cond.notify(); // or notifyAll()
}

void consume() {
    auto lock = cond.lock();
    while (!is_ready(resource))
        cond.wait(lock);
    use(resource);
}

但老实说，我不确定这是否值得麻烦：如果您想使用 recursive_mutex 而不是普通的 mutex 怎么办？好吧，您必须从您的类中制作一个模板，以便您可以选择互斥锁类型（或者完全编写第二个类，是的代码重复）。无论如何，您不会获得太多收益，因为您仍然必须编写几乎相同的代码来管理资源。仅用于 CV/互斥锁对的包装器类太薄，无法真正有用恕我直言。但像往常一样，YMMV。