John,

What's wrong with wrapping the entire API if you happen to want enforceable 
user space locking? Based on the discussion, sharing sockets between threads is 
basically an antipattern for everyone except binding authors, and binding 
authors are effectively wrapping the entire API anyway.

--Dave

-----Original Message-----

Date: Tue, 7 Feb 2012 10:16:21 +1100
From: john skaller <[email protected]>
Subject: Re: [zeromq-dev] Thread Safe sockets
To: ZeroMQ development list <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset=us-ascii


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
[email protected]
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to