问题描述

我正在处理的一个项目使用多个线程来处理一组文件.每个线程都可以将文件添加到要处理的文件列表中，所以我把(我认为是)一个线程安全队列放在一起.相关部分如下:

A project I'm working on uses multiple threads to do work on a collection of files. Each thread can add files to the list of files to be processed, so I put together (what I thought was) a thread-safe queue. Relevant portions follow:

// qMutex is a std::mutex intended to guard the queue
// populatedNotifier is a std::condition_variable intended to
//                   notify waiting threads of a new item in the queue

void FileQueue::enqueue(std::string&& filename)
{
    std::lock_guard<std::mutex> lock(qMutex);
    q.push(std::move(filename));

    // Notify anyone waiting for additional files that more have arrived
    populatedNotifier.notify_one();
}

std::string FileQueue::dequeue(const std::chrono::milliseconds& timeout)
{
    std::unique_lock<std::mutex> lock(qMutex);
    if (q.empty()) {
        if (populatedNotifier.wait_for(lock, timeout) == std::cv_status::no_timeout) {
            std::string ret = q.front();
            q.pop();
            return ret;
        }
        else {
            return std::string();
        }
    }
    else {
        std::string ret = q.front();
        q.pop();
        return ret;
    }
}

但是，我偶尔会在 if (...wait_for(lock, timeout) == std::cv_status::no_timeout) { } 块中出现段错误，并且在 gdb 中检查表明由于队列为空，出现段错误.这怎么可能?我的理解是 wait_for 只在收到通知时返回 cv_status::no_timeout，并且这应该只在 FileQueue::enqueue 之后发生刚刚将一个新项目推送到队列中.

However, I am occasionally segfaulting inside the if (...wait_for(lock, timeout) == std::cv_status::no_timeout) { } block, and inspection in gdb indicates that the segfaults are occurring because the queue is empty. How is this possible? It was my understanding that wait_for only returns cv_status::no_timeout when it has been notified, and this should only happen after FileQueue::enqueue has just pushed a new item to the queue.

推荐答案

根据标准 condition_variables 允许虚假唤醒，即使事件没有发生.在虚假唤醒的情况下，它会返回 cv_status::no_timeout(因为它唤醒而不是超时)，即使它没有被通知.正确的解决方案当然是在继续之前检查唤醒是否真的合法.

According to the standard condition_variables are allowed to wakeup spuriously, even if the event hasn't occured. In case of a spurious wakeup it will return cv_status::no_timeout (since it woke up instead of timing out), even though it hasn't been notified. The correct solution for this is of course to check if the wakeup was actually legit before proceding.

细节在标准 §30.5.1 [thread.condition.condvar] 中指定:

The details are specified in the standard §30.5.1 [thread.condition.condvar]:

——当通过调用 notify_one()、调用 notify_all()、abs_time 指定的绝对超时 (30.2.4) 或虚假发出信号时，函数将解除阻塞.

—The function will unblock when signaled by a call to notify_one(), a call to notify_all(), expiration of the absolute timeout (30.2.4) specied by abs_time, or spuriously.

...

返回: cv_status::timeout 如果 abs_time 指定的绝对超时 (30.2.4) 过期，则为 cv_status::no_timeout.

Returns: cv_status::timeout if the absolute timeout (30.2.4) speciedby abs_time expired, other-ise cv_status::no_timeout.

这篇关于C++11 线程安全队列的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！