[zeromq-dev] Race conditions when creating sockets from different threads?

Martin Sustrik sustrik at 250bpm.com
Mon Feb 8 11:16:32 CET 2010

Steven McCoy wrote:
> On 8 February 2010 17:41, Pavel Gushcha <pavimus at gmail.com 
> <mailto:pavimus at gmail.com>> wrote:
>     Sometimes my multithreaded application is crashed while creating
>     sockets. I wrote simple test (attached) that illustrates the problem.
>     Backtrace is following:
>     #0  0x0000003b2fa81074 in ?? () from /lib/libc.so.6
>     #1  0x0000003b2fa7f47a in memmove () from /lib/libc.so.6
>     #2  0x00007f7b15b3d063 in std::vector<zmq2::socket_base_t*,
>     std::allocator<zmq2::socket_base_t*>
>      >::_M_insert_aux(__gnu_cxx::__normal_iterator<zmq2::socket_base_t**,
>     std::vector<zmq2::socket_base_t*, std::allocator<zmq2::socket_base_t*>
>      > >, zmq2::socket_base_t* const&) () from /usr/lib/libzmq.so.0
> Adding the new socket is an STL vector underneath and is not 
> thread-safe, which is a bit strange considering every other part of 
> create_socket is locked,

>     socket_base_t *s = thread->create_socket (type_);

The point is that 'thread' (zmq::app_thread_t) is 0MQ context associated 
with the OS thread we are running in. Thus, we should never access the 
same instance from two different OS threads. That's why there is no 
locking there.

Btw, I've been able to reproduce the problem. What I've found so far is 
that occasionally, single zmq::app_thread_t is associated with two 
different OS threads - which shouldn't happen. I'm investigating further...


More information about the zeromq-dev mailing list