Re: [zeromq-dev] thread affinity
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. Greg ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread affinity
On Mon, Dec 2, 2013 at 3:15 PM, Greg Ward g...@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. -MinRK Greg ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread affinity
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 jus...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread affinity
On 11/30/2013 10:02 AM, Min RK wrote: On Nov 30, 2013, at 9:30, Justin Karneges jus...@affinix.com wrote: 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. Pyzmq imposes no restrictions on how you use sockets, so it is perfectly possible to share them across threads using locks (or not, and just risk segfault). Good to hear. I could have sworn I hit some attempt to use socket from thread it wasn't created in exception when I tried to do it (even with locking) but it's been awhile so I could be mistaking things. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] thread affinity
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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
