[zeromq-dev] Thread Safe sockets

[Nadav Samet]

I like the concept of having thread-safe sockets, but it seems that this
implementation does not really deliver what a user would expect from a
thread-safe socket. For instance, if two threads try to
receive simultaneously from the same socket, each of them might obtain
different frames that belong to one multipart message. Similarly, sending
messages simultaneously from different threads over the same socket will
get the individual frames intertwined.

There are use cases for locking each individual operation (if you know that
there is at most one thread using the socket at a time), but I think that
ultimately the binding/end-user application knows better than libzmq what
locking semantics it needs for the socket.

-Nadav

On Sat, Feb 4, 2012 at 11:45 AM, john skaller <skaller at users.sourceforge.net
> wrote:

>
> On 04/02/2012, at 9:53 PM, Pieter Hintjens wrote:
>
> > On Sat, Feb 4, 2012 at 1:26 AM, john skaller
> > <skaller at users.sourceforge.net> wrote:
> >
> >> Someone else in the community concerned with performance no doubt has
> >> some test code which performs measurements. Such code would be more
> >> reliable than anything I could write.
> >
> > What I would do, would be to take the current performance test
> > programs (latency and throughput tests) and create versions that use
> > locked sockets. These are pretty effective tools for measuring raw 0MQ
> > performance, if you run local and remote on the same multicore box.
>
>
> I can have a look at that, however the issue here isn't the performance
> of locked sockets, but performance of the old code vs. the new code
> *not using* the new feature: the real issue is how much non-users
> of the locking feature will pay. This is a bit trickier to check (I need
> two
> versions of 0MQ to do it)
>
> The actual cost of using locked sockets has to be compared with the
> cost of "doing it the old 0MQ way" using multi-plexing intermediaries
> as outlined by Chuck previously. The comparison is not just performance
> but also LOC and how easy each is to maintain.
>
> --
> 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
>



-- 
-Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120206/e9484c34/attachment.htm>