c++ - ZeroMQ:如何使用 inproc 减少多线程通信延迟？

Question

我正在使用 inproc 和 PAIR 来实现线程间通信，并试图解决由于轮询引起的延迟问题。如果我错了请纠正我:轮询是不可避免的，因为普通的 recv() 调用通常会阻塞并且不能采取特定的超时。

在我当前的例子中，在 N 个线程中，每个 N-1 工作线程都有一个主 while 循环。第 N 个线程是 Controller 线程，它会随时通知所有工作线程退出。但是，工作线程必须使用超时轮询来获取该 quit 消息。这引入了延迟，延迟参数通常为1000ms。

举个例子

while (true) {
    const std::chrono::milliseconds nTimeoutMs(1000);
    std::vector<zmq::poller_event<std::size_t>> events(n);  
    size_t nEvents = m_poller.wait_all(events, nTimeoutMs); 
    bool isToQuit = false;
    for (auto& evt : events) {
        zmq::message_t out_recved;
        try {
            evt.socket.recv(out_recved, zmq::recv_flags::dontwait);
        }
        catch (std::exception& e) {
            trace("{}: Caught exception while polling: {}. Skipped.", GetLogTitle(), e.what());
            continue;
        }
        if (!out_recved.empty()) {
            if (IsToQuit(out_recved))
               isToQuit = true;
               break;
        }
    }
    if (isToQuit)
       break;
    //
    // main business
    //
    ...
}

更糟糕的是，当主循环有嵌套循环时，工作线程需要在嵌套循环的每一层中包含更多的轮询代码。非常丑陋。

之所以选择ZMQ进行多线程通信，是因为它的优雅和摆脱线程锁的潜力。但我从未意识到轮询开销。

在使用常规互斥锁或 std::atomic 数据操作时，我能否达到典型的延迟？我是否应该理解 inproc 实际上是一种伪装的网络通信模式，因此一些延迟是不可避免的？

Answer 1

上面发表的声明(一个假设):

"...a plain recv() call will usually block and cannot take a specific timeout."

不正确:
一个普通的 .recv( ZMQ_NOBLOCK ) 调用永远不会“阻塞”，
一个普通的 .recv( ZMQ_NOBLOCK ) 调用可以被修饰以模仿“特定超时”

上面发表的声明(一个假设):

"...have to use polling with a timeout ... introduces a latency, the latency parameter is usually 1000ms."

不正确:
- 不需要使用带超时的轮询
- 较少的不需要设置 1000 ms 代码-“注入(inject)”-延迟，显然只花费在无新消息状态

Q : "Am I able to achieve the typical latency when using a regular mutex or an std::atomic data operation?"

是的。

Q : "Should I understand that the inproc is in fact a network communication pattern in disguise so that some latency is inevitable?"

没有。 inproc-transport-class 是所有这些类型中最快的，因为它主要是无协议(protocol)/无堆栈的，并且与最终快速指针机制有更多关系，例如在双端环形缓冲区指针管理中。

---

最佳下一步:

1 )
重构您的代码，以便始终利用零等待 { .poll() | .recv() }-方法，为两个 { event- |无事件- }-特定循环。

2)
如果那么愿意从智能循环检测周转时间中缩短最后几个[us]，可能会专注于改进Context( )-instance 将其设置为与大量的 nIOthreads > N “在后台”一起工作。

可选 3 )
对于几乎硬实时系统的设计，人们可能最终利用确定性驱动的Context()-threads'和这些执行载体到特定的套接字特定映射，非重叠 CPU 核心(使用精心制作的亲和图)

---

在代码中设置了 1000 [ms] 后，没有人会提示花费这 1000 [ms] 等待超时，由她/他自己编写代码。没有理由这样做。

不要将行为归咎于 ZeroMQ，这是从 API 的应用程序端编码的。

从不。