[zeromq-dev] Thread Safe sockets

[john skaller]

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