On Tue, Apr 15, 2014 at 11:23:15AM +0800, Dong Mo wrote:
> Dear list,
>
> I am very new to zmq and noticed in
> http://zguide.zeromq.org/page:all#Multithreading-with-MQ that it seems to
> be a good idea to replace mutex with message passing in zmq.
>
> But my question is that how should I exactly transform from the notion of
> mutex, conditional variable and etc to the thinking pattern of zmq.
>
> Here is an example I encountered:
>
> I have thread A, B, C. They will all modify state S. In the past, I will do
> lock on this shared state and they can coordinate, but I don't know how to
> express the mutex semantic using zmq. One way I think of is that I create
> another thread D and let A,B,C communicate with D over zmq when they want
> to manipulate S, and there will be no race condition since D is
> coordinating everything. But I feel that this is definitely not the best
> practice...
>
> So could you inform me what is it and why it is worthwhile to use zmq
> instead of mutex
>
> Sorry if this question is naiive, still trying to figure things out.
>
> Thank you very much
> -Mo
Taking a solution specifically design for mutexes and trying to
implement that in ZMQ is probably a bad idea. If you use your idea and
have a thread D to manage the state then A, B and C will frequently
contact D and wait for a reply. That will be a lot slower than the
mutex.
Instead you should forget about your existing solution and look at the
problem with fresh eyes.
I find message passing works best if you can build pipelines of
workers that each do their part and then send the result to the next
station. A new job comes in and gets send to A. A does some work and
sends the result to B. B does its part and send it on to C. C finishes
the work and outputs the result.
If the pipeline is linear then fine. But you can also have multiple
pipelines, branches, fan out and fan in and even loops. Although loops
can be dangerous without some buffering element to avoid a deadlock
when the loop gets too full.
What you should avoid is a request - wait-for-reply pattern. If you
have to wait for the reply then you are not doing any work. It's
better to send of the request and forget about it. Start some other
work and maybe send more requests. Then when the reply comes back
later you pick up the work again. Alternatively split the Job so
A->B->A becomes A->B->A'.
MfG
Goswin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
