[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