[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