[zeromq-dev] zmq_ctx_term hang

[gonzalo diethelm]

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: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] 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 <michi at triodia.com<mailto:michi at triodia.com>> 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140414/797b650e/attachment.htm>