[zeromq-dev] Thread Safe sockets
martin at lucina.net
Tue Feb 7 02:24:36 CET 2012
On Tue, 7 Feb 2012 12:11:10 +1100
john skaller <skaller at users.sourceforge.net> wrote:
> On 07/02/2012, at 11:23 AM, Martin Lucina wrote:
> > The "each thread has its own inproc socket" model is really nice and we
> > should emphasise it more. It leads to developing your applications
> > around messaging and concurrency, and IMO is a much more elegant way of
> > dealing with concurrency than the "old school" locks and shared state
> > model.
> It's not old school. Messaging/process and shared state have their own uses.
> There are plenty of applications where messages would be ridiculous.
Sure. What I meant by old school is that there's a lot of code out
there which has had threading bolted-on after the fact, usually by
using one or a few big locks.
> But what I really want to address here is the misconception that 0MQ provides
> a complete way to deal with synchronisation, using inproc.
I'm not suggesting that "messaging is the one true way", or that
"using inproc sockets in ZeroMQ encompasses all possible use-cases for
synchronization". If anything, I try to stay away from statements like
> AFICS, it doesn't (correct me if I'm wrong!): ZMQ sockets are buffered,
> so the synchronisation is sloppy. This is often OK, but it is isn't a
> universal solution. It's unreliable (messages
> can be dropped) and it's slow compared to a lock.
Buffered in the sense that it's asynchronous and can be delayed, yes.
It's reliable in the sense that *if* you use the correct socket type
(*NOT* PUB/SUB!) and set infinite HWMs, then no messages will be dropped
as long as the socket is around. So no, not unreliable.
> The thing is: at present, the thread-safe socket interface provided does not
> in any way interfere with anything. If you don't use it, you have the old 0MQ
> non-safe socket model.
Yup, but IMHO it goes against encouraging people to use ZeroMQ "the
right way" :-/
Martin Lucina <martin at lucina.net>
More information about the zeromq-dev