asio :: async_write在大容量流上难以同步

时间:2019-05-20 23:32:27

标签: c++ multithreading mutex deadlock condition-variable

我目前正在使用Asio C ++库,并围绕它编写了一个客户端包装。我最初的方法非常基础,只需要向一个方向传送即可。需求已更改,我已切换为使用所有异步调用。除asio::async_write(...)外,大多数迁移都很容易。我使用了几种不同的方法,并且不可避免地陷入了僵局。

应用程序连续大量传输数据。我没有使用多线程,因为它们不会阻塞,并且可能导致内存问题,尤其是在服务器负载沉重的情况下。作业将备份,应用程序无限期地增长。

因此,我创建了一个阻塞队列,只是为了找出在回调之间使用锁或阻塞事件导致未知行为的困难方法。

包装器是一个非常大的类,所以我将尝试解释我的现状,并希望得到一些好的建议:

  • 我有一个asio::steady_timer,它按照固定的时间表运行,将心跳消息直接推入到阻塞队列。
  • 专用于读取事件并将其推入到阻塞队列的线程
  • 专用于阻塞队列的消耗的线程

例如,在我的队列中,我有一个queue::block()queue::unblock(),它们只是条件变量/互斥锁的包装。

std::thread consumer([this]() {
    std::string message_buffer;

    while (queue.pop(message_buffer)) {
        queue.stage_block();
        asio::async_write(*socket, asio::buffer(message_buffer), std::bind(&networking::handle_write, this, std::placeholders::_1, std::placeholders::_2));
        queue.block();

    }
});

void networking::handle_write(const std::error_code& error, size_t bytes_transferred) {
    queue.unblock();
}

当套接字备份并且服务器由于当前负载而无法再接受数据时,队列将填满并导致死锁,其中永远不会调用handle_write(...)

另一种方法完全消除了使用者线程,并依靠handle_write(...)来弹出队列。像这样:

void networking::write(const std::string& data) {
    if (!queue.closed()) {
        std::stringstream stream_buffer;
        stream_buffer << data << std::endl;

        spdlog::get("console")->debug("pushing to queue {}", queue.size());

        queue.push(stream_buffer.str());

        if (queue.size() == 1) {
            spdlog::get("console")->debug("handle_write: {}", stream_buffer.str());
            asio::async_write(*socket, asio::buffer(stream_buffer.str()), std::bind(&networking::handle_write, this, std::placeholders::_1, std::placeholders::_2));
        }
    }
}

void networking::handle_write(const std::error_code& error, size_t bytes_transferred) {
    std::string message;
    queue.pop(message);

    if (!queue.closed() && !queue.empty()) {
        std::string front = queue.front();

        asio::async_write(*socket, asio::buffer(queue.front()), std::bind(&networking::handle_write, this, std::placeholders::_1, std::placeholders::_2));
    }
}

这也导致了死锁,并且显然导致了其他种族问题。当我禁用心跳回调时,我绝对没有问题。但是,心跳是必需的。

我在做什么错?有什么更好的方法?

1 个答案:

答案 0 :(得分:0)

看来我所有的痛苦完全源于心跳。在异步写操作的每个变体中禁用心跳似乎可以解决我的问题,因此这使我相信这可能是由于使用内置的asio::async_wait(...)asio::steady_timer造成的。

Asio在内部同步其工作,并在完成下一个作业之前等待作业完成。使用asio::async_wait(...)构造我的心跳功能是我的设计缺陷,因为它在等待挂起作业的同一线程上运行。当心跳等待queue::push(...)时,它与Asio产生了死锁。这可以解释为什么在我的第一个示例中从未执行过asio::async_write(...)完成处理程序。

解决方案是将脉动信号置于其自己的线程上,并使其独立于Asio而工作。我仍在使用阻塞队列来同步对asio::async_write(...)的调用,但已将我的使用者线程修改为使用std::futurestd::promise。这样可以使回调与我的使用者线程完全同步。

std::thread networking::heartbeat_worker() {
    return std::thread([&]() {
        while (socket_opened) {

            spdlog::get("console")->trace("heartbeat pending");
            write(heartbeat_message);
            spdlog::get("console")->trace("heartbeat sent");

            std::unique_lock<std::mutex> lock(mutex);
            socket_closed_event.wait_for(lock, std::chrono::milliseconds(heartbeat_interval), [&]() {
                return !socket_opened;
            });
        }

        spdlog::get("console")->trace("heartbeat thread exited gracefully");
    });
}