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

上面发布的声明（假设）：

“......一个普通的recv()调用通常会阻塞并且不能采取特定的超时。”

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

上面发布的声明（假设）：

“......必须使用超时轮询......引入延迟，延迟参数通常为1000ms 。 ”

是不正确的：
- 无需使用超时轮询
- 较少的一个不需要设置 1000 毫秒代码-“注入”-延迟，显然只花费在-no-new-message state

问： “使用常规mutex或std::atomic数据操作时，我能否实现典型的延迟？”

是的。

问： “我是否应该理解inproc实际上是一种伪装的网络通信模式，因此一些延迟是不可避免的？”

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

---

最好的下一步：

1)
重构您的代码，以便始终利用零等待{.poll() |.recv() } -方法，为 { event- | no-event- }-specific 循环。

2)
如果然后愿意从智能循环检测周转时间中减少最后几个[us] ，则可以专注于改进Context() -instance 将其设置为与更大数量的nIOthreads > N “在引擎盖下”一起工作。

可选 3)
对于几乎硬实时系统的设计，最终可以利用确定性驱动的Context()线程和这些执行载体到特定的、非重叠的 CPU 内核的特定套接字映射（使用精心设计的亲和力-地图 ）

---

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

不要责怪 ZeroMQ 的行为，这是从 API 的应用程序端编码的。

绝不。