[zeromq-dev] Threading questions
sustrik at 250bpm.com
Fri Feb 19 15:01:48 CET 2010
gonzalo diethelm wrote:
>> You should access each socket from only one thread. Therefore there's
>> 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
Thanks! This kind of thing is always nice to hear.
More information about the zeromq-dev