7

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

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

我已经围绕 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 需要一个而不是直接使用互斥锁，所以这可能是问题的原因。我在网上找不到很好的解释。

4

1 回答 1

9

前言：理解条件变量的重要一点是它们可能会受到随机、虚假的唤醒。换句话说，一个 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()同时调用而不用担心 shared unique_lock：唯一共享的东西是mutex/cv/resource，每个线程都有自己的东西unique_lock，如果互斥锁已被其他东西锁定，则强制线程等待轮到它。

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

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

如果您真的只想包装 CV/互斥锁对，您应该摆脱lock()/release()不安全的方法（从 RAII 的角度来看）并用lock()返回 a 的单个方法替换它们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);
}

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

于 2013-07-25T12:45:52.610 回答