In general, a ring-buffer is needed for a realtime Producer thread to have decent performance.
But in my case, I have some latency constraints, so I'd love to get rid of the ring-buffer from Producer and push individual data buffers out as they come along. I'd then ring-buffer on the Consumers (slower) side only. And I'd love to avoid thread locking via critical sections.
Since ZMQ requires no thread-locking, I wonder if a inproc PubSub pattern can be used for this. Knowing network I/O is not welcomed in a realtime thread, I'm still curious about whether or not the inproc protocol could make any difference, i.e., better performance.
So the question is: Can I achieve low-latency lock-free/blocking-free data delivery in a realtime thread using ZMQ PubSub with inproc protocol?
Q : Can I achieve low-latency lock-free/blocking-free data delivery in a realtime thread using ZMQ PubSub with
inprocprotocol?
Yes.
Just enough to instantiate a thread-less Context(0)-instance :
No I/O threads are involved in passing messages using the inproc transport. Therefore, if you are using a ØMQ context for in-process messaging only you can initialise the context with zero I/O threads
Affinity (wisely planned bonding) tricks may shave-off further a few hundreds [ns] due to possible avoiding all R/T processing from bearing extensive add-on latency-costs from core-to-core NUMA-non-local memory accesses.