[zeromq-dev] Thread Safe sockets

[john skaller]

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.

But what I really want to address here is the misconception that 0MQ provides
a complete way to deal with synchronisation, using inproc.

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.

Felix pchannels are synchronisation points, in fact it is a happy artefact
of the channel concept that you can actually transfer data (a message)
as well. The data is not important: its the synchronisation that matters.

Secondly, there's a lot of extra stuff to do to provide extra sockets
to get sloppy synchronisation when in fact a lock would be easy.
Just look at the example in the test cases:

	tests/test_ts_context.cpp

to see how easy it is to use the thread-safe feature.

I am NOT against using channels for synchronisation as 0MQ does.
In fact Felix is designed to do precisely that! 

Actually, the argument:

"""
2. Binding authors (usually for garbage collected languages) find that having thread safe sockets would make their lives easier when working with the host language. This seems to be less about multi-part messages, and more about socket cleanup.

Is there something wrong with the implementation allowing thread-safe sockets for binding authors, but yet strongly advocating a socket-per-thread behaviour in userspace?
"""

is quite compelling. There are two issues:

1. The binding would no longer be just a wrapper around ZMQ. YMMV. The binding
author would have to document the behaviour.

2. I personally regard 0MQ as a C++ system, and the C API as a binding.
So actually .. we're talking about a binding :)

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.

--
john skaller
skaller at users.sourceforge.net