[zeromq-dev] thread affinity

Justin Karneges justin at affinix.com
Sat Nov 30 18:30:53 CET 2013

Great, it sounds like the answer to my question is that it is possible 
to use the same socket from different threads provided I do my own 
locking. That's perfectly workable. I mainly wanted to be sure there 
wasn't something in libzmq explicitly preventing this kind of usage. For 
example, I believe it is impossible to share a socket across threads 
with pyzmq, but this must be a limitation imposed in the binding rather 
than in libzmq.

On 11/30/2013 01:05 AM, Pieter Hintjens wrote:
> Hi Justin,
> This is an area of some debate. We've had patches to libzmq that made
> sockets thread safe, and removed those patches again. Sharing sockets
> between threads for the most part is bad for design and performance.
> However there are languages where this just essential, for the reasons
> you describe.
> My advice would be to solve this in the language binding. Simply
> create socket access routines (send/recv) that do the necessary
> locking.
> -Pieter
> On Sat, Nov 30, 2013 at 7:30 AM, Justin Karneges <justin at affinix.com> wrote:
>> Hi folks,
>> What's the latest on the thread-safety of sockets? I know that normal
>> 0MQ practice suggests not using a socket from multiple threads, but I
>> wonder if this is nonetheless possible, for example by wrapping a mutex
>> around access.
>> The reason I ask is I'm exploring the possibility of using 0MQ in a
>> hybrid event-driven & threaded C++ environment (imagine something like
>> Goroutines or .NET tasks). A socket would never be used by two threads
>> simultaneously, but the thread on which a socket is utilized could
>> change depending on how the eventing system dispatches work. For
>> example, a task executing in one thread could go to sleep while it waits
>> for a message and then wake up in a different thread when a message
>> becomes available.
>> I just want to confirm that this is a valid usage of 0MQ, before I do
>> something that might not be possible or might get broken in a future
>> release.
>> Justin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list