[zeromq-dev] Threading questions

[Martin Sustrik]

gonzalo diethelm wrote:

>> You should access each socket from only one thread. Therefore there's
> no
>> need for synchronisation.
> 
> Yes, but the question is regarding 0MQ's _context_. When I create a
> socket within a thread, I pass the context as a parameter; should that
> be protected with a mutex?

Context object is thread safe. In overall, you don't have to care about 
synchronisation at all: context object is thread-safe and each socket is 
used from one thread only.

>>> Then the answer would be yes? I said "more than one thread calling
>>> zmq_recv() on DIFFERENT sockets at the same time".
>> Hm. One thread cannot do two things at the same time. So it can access
>> at most one socket at a time.
> 
> Just to clarify. I knew you are not supposed to call recv() on the SAME
> socket from DIFFERENT threads. Now it is clear you CAN call recv() on
> DIFFERENT sockets from DIFFERENT threads (and without using any mutex).

Yes, sure. The different sockets may be called from two different 
threads at the same time.

Moreover, 0MQ is designed for scalability meaning that inside 0MQ each 
socket is completely separated from all other sockets. Thus each socket 
can run on its CPU core without ever having to synchronise with a 
different CPU core.

>> Which implies the uni-directionality, but you are right, it should be
>> made more explicit.
> 
> Which brings me to a sort of a more generic request: I have been missing
> all along a more high-level description of 0MQ (2.0 particularly):
> architecture, design goals, types of sockets, use cases, etc. You can
> certainly build a picture from all the scattered documents, but they are
> scattered, some are for 1.0 and some things are not really spelled out
> anywhere. It would be really nice if the About section on the web site
> gave more high-level details about ZMQ.

The biggest problem with detailed documentation is that it consumes a 
lot of resources. If you know anyone who would be willing to pay for 
that, just let me know :)

In any case, Martin Lucina is now working on improving the documentation 
and when we were discussing it lately, we've kind of agreed on adding 
man pages for each messaging pattern (request/reply, publish/subscribe, 
message streaming) - that may make most of the points you are pointing 
out more clear.

> Again, this is not to say anything bad about the project. In my case,
> ZMQ matches so closely with what I have been looking for, it is almost
> uncanny. 

Thanks! This kind of thing is always nice to hear.

Martin