实时线程中的 ZeroMQ inproc PubSub send() 调用会导致严重阻塞吗？答案

【问题标题】：Will a ZeroMQ inproc PubSub send() call in a realtime thread cause serious blocking?实时线程中的 ZeroMQ inproc PubSub send() 调用会导致严重阻塞吗？
【发布时间】：2020-01-27 07:29:50
【问题描述】：

一般来说，实时生产者线程需要一个环形缓冲区才能获得良好的性能。

但就我而言，我有一些延迟限制，所以我很想摆脱 Producer 的环形缓冲区，并在个别数据缓冲区出现时将它们推出。然后，我只会在消费者（较慢）端进行环形缓冲区。而且我很想避免通过关键部分进行线程锁定。

由于 ZMQ 不需要线程锁定，我想知道是否可以为此使用 inproc PubSub 模式。知道网络 I/O 在实时线程中不受欢迎，我仍然很好奇 inproc 协议是否可以产生任何影响，即更好的性能。

所以问题是：我能否使用带有inproc 协议的 ZMQ PubSub 在实时线程中实现低延迟的无锁/无阻塞数据传输？

【问题讨论】：

标签： c++ multithreading locking zeromq nonblocking

【解决方案1】：

Q：我能否在实时线程中使用带有inproc 协议的 ZMQ PubSub 实现低延迟的无锁/无阻塞数据传输？

是的。

足以实例化一个无线程Context(0)-instance：

使用 inproc 传输传递消息时不涉及任何 I/O 线程。因此，如果您仅使用 ØMQ 上下文进行进程内消息传递，则可以使用零 I/O 线程初始化上下文

Affinity（明智地计划的绑定）技巧可能会进一步减少数百个[ns]，因为可能避免所有 R/T 处理承受来自核心到核心 NUMA-non-local 的大量附加延迟成本内存访问。

【讨论】：

@kakyo 很高兴您发现它有趣且鼓舞人心 - StackOverflow 鼓励社区成员单击 [+1] 以获取问题或答案中的此类有趣或鼓舞人心的项目，然后单击 [接受] 以获得最佳答案到目前为止已为您的问题提供，所以请不要犹豫 - StackOverflow 以这种方式工作（如您所知：o）
哦，是的。我会在核实后立即接受。大概明天吧。