Hi Michi, If you share a 0mq socket among threads, and make sure each thread acquires the mutex before doing anything with the socket, you should be fine. This is not a very common pattern though, hence the "should".
You could also consider using inproc sockets to communicate between the thread owning the "real" socket (a single thread, no mutexes) and the threads that will do the work. HTH. Best regards, -- Gonzalo Diethelm DCV Chile From: [email protected] [mailto:[email protected]] On Behalf Of Michi Henning Sent: Sunday, April 13, 2014 7:02 PM To: ZeroMQ development list Subject: Re: [zeromq-dev] zmq_ctx_term hang OK, turns out that the culprit was that it was possible for the destructor of one of my classes to be called from a different thread than the constructor. There was a socket class member in that class, so the open and close on the socket could be called from different threads, which is a no-no. I'd like to follow up with a question though. If anyone can help with this, that would be awesome! From the FAQ: For those situations where a dedicated socket per thread is infeasible, a socket may be shared if and only if each thread executes a full memory barrier before accessing the socket. Most languages support a Mutex or Spinlock which will execute the full memory barrier on your behalf. Now, from this, I take it that it would be correct (if not encouraged) to have thread A create a socket while holding a mutex, have thread B some time later call send() on the socket while holding the mutex, and then have thread A some time later call close() on the socket, also while holding the mutex? What about the following scenario? 1. Thread 1 locks mutex, creates socket, and never uses the socket again. 2. Thread 2 locks mutex, calls send(), and never uses the socket again. 3. Thread 3 locks mutex, and calls close() on the socket. Where all this rears its head for me is that I need to shut down a number of worker threads. I'm using the PUB/SUB pattern recommended in the guide, with the worker threads polling on the SUB to find out when they are supposed to go away. The problem is that I don't have a dedicated thread that ends up publishing the stop message; instead, the stop can be triggered by arbitrary application threads (of whose existence I don't even know). If I do the naive thing and just create the PUB socket from the calling thread at the time the stop message needs to be sent, I end up with the slow joiner problem. That problem goes away if I use inproc instead of ipc, but that's not really a clean solution because, in theory, the implementation of inproc could change in the future. I know, I could just keep a dedicated thread that creates the socket, sleeps, wakes up when the stop needs to be sent, does the send(), and then the close(). But that seems a bit heavy-weight, as does a solution where a dedicated thread listens for a stop message on an inproc PULL socket and then writes the stop message to the PUB socket (so I can avoid the slow joiner syndrome with ipc, and make sure that I bind() to the PUB before any subscribers connect to the SUB with the inproc transport). Thanks, Michi. On 2 Apr 2014, at 2:30 , Michi Henning <[email protected]<mailto:[email protected]>> wrote: Thanks Gonzalo (and Pieter and Andrew). I'll work on that and see what I can come up with. Cheers, Michi. ----------------------------------------- Declaración de confidencialidad: Este Mensaje esta destinado para el uso de la o las personas o entidades a quien ha sido dirigido y puede contener información reservada y confidencial que no puede ser divulgada, difundida, ni aprovechada en forma alguna. El uso no autorizado de la información contenida en este correo podrá ser sancionado de conformidad con la ley chilena. Si usted ha recibido este correo electrónico por error, le pedimos eliminarlo junto con los archivos adjuntos y avisar inmediatamente al remitente, respondiendo este mensaje. "Before printing this e-mail think if is really necesary". Disclosure: This Message is to be used by the individual, individuals or entities that it is addressed to and may include private and confidential information that may not be disclosed, made public nor used in any way at all. Unauthorized use of the information in this electronic mail message may be subject to the penalties set forth by Chilean law. If you have received this electronic mail message in error, we ask you to destroy the message and its attached file(s) and to immediately notify the sender by answering this message.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
