[zeromq-dev] Threading questions

Martin Sustrik sustrik at 250bpm.com
Fri Feb 19 13:53:55 CET 2010


gonzalo diethelm wrote:

> Got it. Do I have to protect access to 0MQ's context with a mutex within
> each thread?

You should access each socket from only one thread. Therefore there's no 
need for synchronisation.

Actually, that's the goal of the whole thing, having to do lock/unlock 
on each call to 0MQ would decrease performance by an order of magnitude.

>>> Can I have more than one thread calling zmq_recv() on different
> sockets
>>> at the same time?
>> No. Each socket object can be created and used from at most one
> thread.
>> For communication between threads use inproc transport (zmq_inproc(7))
> 
> 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.

>> See an example here:
>>
>> http://www.zeromq.org/area:docs-v20#toc15
> 
> The example only shows one inproc socket being used to communicate
> between two threads. I assume one of the threads can then go on to
> create other socket(s), right?

There are two sockets there, but I've named both of them 's' which made 
the example confusing. Have a look at it now. The socket owned by the 
main thread is called 'sm', the one owned by the worker thread is called 
'sw'.

> You are right. Which makes me wonder: are pub/sub and
> upstream/downstream sockets inherently one-way? I don't remember seeing
> any explicit statement to this effect in the docs.

Yes, they are.

You have statements like this in zmq_socket(3):

ZMQ_PUB - Socket to distribute data. Recv fuction is not implemented for 
this socket type.

Which implies the uni-directionality, but you are right, it should be 
made more explicit.

Martin




More information about the zeromq-dev mailing list