[zeromq-dev] thread affinity

MinRK benjaminrk at gmail.com
Tue Dec 3 02:47:42 CET 2013

On Mon, Dec 2, 2013 at 3:15 PM, Greg Ward <greg at gerg.ca> wrote:

> On 30 November 2013, Pieter Hintjens said:
> > 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.
> But doesn't that mean holding a lock during a potentially blocking
> operation? E.g. if I send() to a REQ socket that has hit its
> high-water mark, send() will block. If I'm holding a mutex during that
> operation, than other threads can block on that mutex for a long time.
> That sort of nasty cascading lock situation can go very bad very
> quickly in my experience.

You are holding a lock on a resource while it's not safe for another thread
to use it. If you have significant contention on one of these locks, it
means you are trying to have significant concurrent access on a single
socket, and the lock will effectively serialize those threads. This is
really why sharing sockets across threads is ill advised.  You can use
locks to move a socket from one thread to another, but it is only useful if
that transaction is sufficiently rare, such as when blocking zmq calls are
a minority of your app's run time.


>        Greg
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131202/3b490fe4/attachment.htm>

More information about the zeromq-dev mailing list