[zeromq-dev] Thread Safe sockets

[Martin Lucina]

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
that :-)

> 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" :-/

-mato
-- 
Martin Lucina <martin at lucina.net>