[zeromq-dev] Thread-safe sockets (cont.)

Daniel Lundin dln at eintr.org
Fri Feb 17 13:11:26 CET 2012

I think zmq should maintain a single, consistent, opinion on concurrency.

In a typical application right now, one federates messages to multiple
[worker] threads using an inproc device.

It might be slightly more work than a simple synchronized queue, but
otoh you're using zmq for a reason - typically to avoid locks, scale
easily and to keep things simple.

I quite enjoy this model, and it encourages sound reasoning about concurrency.

I might misunderstand, but it seems counterproductive to add a
separate mode of operation where a zeromq socket is "thread-safe by
default", and have it only be distinguishable by a flag.

If anything, it would be beneficial to actively *prohibit* access to
sockets from "other" threads to enforce safety.

Just my thoughts...

On Fri, Feb 17, 2012 at 08:07, Justin Karneges <justin at affinix.com> wrote:
> I apologize for jumping in mid-conversation, but I see two thread-safety
> goals:
> 1) 0MQ has no built-in locks on sockets.  Applications may use a socket in
> different threads provided the application itself uses its own locks around the
> socket accesses.
> 2) 0MQ has its own locks built-in, so you can use a socket in different threads
> and the application does not need its own locking.
> As I understand it, the current stable 0MQ does not even allow #1.  At least,
> I have read documentation stating that a socket should not be used except in
> the thread it was created in, meaning sockets have thread-affinity.  Is this
> true?
> I personally would like to see #1 solved if it has not been already.  I think
> it should "just work", but offering a function to change thread affinity of a
> socket would be acceptable.  Otherwise, 0MQ is "thread impossible", which to
> me is much worse than "not thread safe". :)
> I have no need for #2 and I think it's overkill.  The only justification I can
> see for it is if 0MQ is trying to emulate posix/kernel behavior and this is a
> necessity in its long term goals.
> On Thursday, February 16, 2012 10:53:19 PM Marten Feldtmann wrote:
>> I am by far no expert in 0MQ, but actually the question of thread-safe
>> socket is no question any more for me. It has been written in the
>> documentation in a clear way, that one should not use sockets from
>> different threads. Over the last weeks - and due to a question from me -
>> it was in a more detailed way explained, what is allowed to do and what
>> not. These informations should be added to the documentation.
>> I've no problem to follow this guideline in my Smalltalk language
>> binding. Its ok and I can work with it and I offer a thread safe
>> interface to the 0MQ library. When people starts working around my
>> "official" language binding - ok, then its their fault. I can not and
>> would not like to forbid this - I assume, that others also might know
>> how to use the 0MQ library. Therefore: leave the decision to the end
>> user and give them enough information so that it can make their own
>> decisions based o this free available information.
>> I like 0MQ because it has such a small C-level API and it is easy to
>> use. The examples guides are well done and show how to use it.
>> Perhaps thread-safe sockets are a nice marketing idea. Some people might
>> think, that this is an absolute must to have - and without that a
>> library is not a reliable piece of software. It is perhaps the same as
>> thinking, that dynamic typed languages are a regressive step in CS. At
>> least this last idea is simply wrong and has been shown over the last 50
>> years in CS.
>>  > There is an analogue in Posix: optional locking. It's fairly useless.
>>  > Because anyone can write into a locked region of a file by ignoring
>>  > the locks.
>> This optional locking is quite a good design pattern: Perhaps the base
>> system contains an error and the strict locking prevents you from doing
>> the last emergency execution step. Its then always good to have the
>> choice (thats the keyword in building libraries) of turning of this
>> locking ...
>> Marten
>> Am 17.02.2012 02:56, schrieb john skaller:
>> > It's not entirely useless but in todays world software is so complex
>> > people want rigid guarantees of correctness for some things, because
>> > there are always a heap of other things where there are no assurances:
>> > [casts in C .. dynamic typing in web applications OMG what a regressive
>> > step in CS]
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list