[zeromq-dev] Thread Safe sockets

[Lucas Hope]

Hi all,

I've read this thread and learned a lot. Here is the gist of what I've got:

1. Thread safe sockets allow abuse and mis-use at the user level. A (The?)
major point of zeromq is to simplify communication between processes so
nasty things like mutexes and other shared structures don't get in the way
of clear, efficient multi-processing. From this perspective, users really
should look to using zeromq for the purpose it was designed for.

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?

(With respect to multi-part messages, I like being able to add
message(frame)s to a zeromq socket and trust the zeromq queue to do things
correctly. So my dealer workers can just pull an envelope stack off the
socket and push it right back on, and then get down to their work.)

-Luke

On Tue, Feb 7, 2012 at 10:16 AM, john skaller <skaller at users.sourceforge.net
> wrote:

>
> On 07/02/2012, at 9:01 AM, Martin Sustrik wrote:
>
> >> This is why I think the locking should be only implemented at
> >> the application/binding level. Only the application knows if everything
> >> that needs to be sent is available and it makes sense to lock the socket
> >> around a tight loop that sends a whole message.
> >
> > Yes, makes sense.
>
> No, it doesn't. I'm picking on Martin here but really it seems no-one
> understands
> the problem properly. So lets be clear:
>
> User space locking cannot be done properly. In particular it is not safe
> because
> it cannot be enforced without wrapping the entire API and hiding ZMQ API.
>
> IT HAS to be done by ZMQ itself. Here's why:
>
> Suppose you write a wrapper for send:
>
>        safe_send( mutex_t &m, data .. ) ... zmq_send ...
>
> You can't enforce usage. Someone might still call zmq_send. But there's
> worse!
> Where does the mutex go?
>
> The only way you can actually lock the socket is to associate a mutex with
> the socket.
> No great problem with one socket. But if you have many sockets you have to
> use
> something like this:
>
>        struct socket_and_mutex { mutex_t m; socket_t s; };
>
> to keep the mutex together with the socket. Now, you call
>
>        safe_send (socket_and_mutex ...)
>
> instead. Fine...
>
> Except now you have wrapped both the data type AND the functions .. you're
> no longer
> using ZMQ. If you're in C++ and you wrap it with private data for
> encapsulation ..
> then you actually enforce it.
>
> The fact no one seems to understand this is STRONG argument for putting
> the thread
> safety inside ZMQ and NOT in the application logic.
>
> It's a fact .. I myself didn't understand it until just now. The
> application cannot do it
> without replacing ZMQ.
>
> --
> john skaller
> skaller at users.sourceforge.net
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
---------------------------------------------------
Dr Lucas Hope - lucas.r.hope at skype
Machine Learning and Software Engineering Consultant
Melbourne, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120207/9d50c687/attachment.htm>