[zeromq-dev] Thread Safe sockets

Chuck Remes cremes.devlist at mac.com
Fri Feb 3 17:19:22 CET 2012


On Feb 3, 2012, at 10:05 AM, john skaller wrote:

> 
>> A mutex works fine with a 0mq socket so adding one to the socket itself would also work. I just don't think it would perform well plus everyone would have to pay that price even if they didn't need it. Yuck.
> 
> I have implemented (but not tested) thread safe sockets, available in Pull request.

You're lucky that the lack of tests isn't a problem for merging to master. We do require tests for patches to stable branches. If I have time today I'll try and get this merged (but I'm leaving town for a few days so I might not get to it until Monday).

> YMMV. Perhaps it should go in a branch or not get pulled at all.
> 
> One function is added to the C API:
> 
> 	zmq_init_thread_safe (nthreads)
> 
> If this function is used, all C API socket functions on any socket spawned by that
> context will be wrapped in a mutex.
> 
> There is no semantic impact on any existing C or C++ code. 
> Calls internal to ZMQ C++ code base are not affected.
> 
> Cost, memory, everyone pays: one bool in context and one bool and one mutex in socket.
> Cost, speed, everyone pays: currently two tests in every C API socket call.
> Could be reduced to one at he expense of duplicating the C++ method call.
> 
> There is no way to selectively turn on or off socket thread safety from the C API.
> 
> BUGS: I deliberately used a "set" method to allow the C++ constructor arguments
> to remain unchanged: attempting to provide minimal interference to any
> existing ZMQ core C++ code.
> 
> This required exposing a "set" method on the sockets.
> It is NOT safe to call that method, but I can't protect it or the C API wouldn't
> be able to access it. This should be fixed if the patch proves useful.
> 
> I have no real input on its utility. It may help in some bindings such as Java.
> It may also be useful in "utilities" where functionality and rapid prototyping
> are more important than performance.

We'll let the community decide. In my role as a maintainer, I have no opinion on patches. :)

cr




More information about the zeromq-dev mailing list