[zeromq-dev] Thread Safe sockets

[Dave Duchene]

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 <skaller at users.sourceforge.net>
Subject: Re: [zeromq-dev] Thread Safe sockets
To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
Message-ID:
	<50AD63AC-C4E8-470B-8590-35B8C037D42C at users.sourceforge.net>
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
skaller at users.sourceforge.net