Boost C++ Libraries: Ticket #8538: asio: race condition for epoll & kpoll

attachment set

Wed, 01 May 2013 20:37:16 GMT

attachment → epoll_reactor.ipp.patch

patch for boost/asio/detail/impl/epoll_reactor.ipp

Wed, 01 May 2013 20:49:02 GMT

I ran into above problem when one thread was calling read operations on socket, while another thread, on certain conditions, was calling close on the same socket object.

I know that on one hand asio's documentation states that asio's basic_datagram_socket, basic_stream_socket are not thread safe for shared objects, but on the other hand - asio's code already has mutexes and locks.

In my mind it would be logical to either completely remove locking, since documentation does not make any guarantees about thread safety, or make sure that existing locks perform protection correctly.

Thanks for taking time to consider my thoughts.

component changed; owner set

viboes — Mon, 13 May 2013 21:31:39 GMT

owner set to chris_kohlhoff
component None → asio

anonymous — Tue, 14 May 2013 19:54:08 GMT

free_descriptor_state does not destroy the descriptor_state. Instead, if marks it as being reusable within the object_pool. Thus, the mutex::scoped_lock will safely unlock the safe mutex it had originally locked. The mutex is only used to protect internal state information. It would be unfortunate if applications had to pay for additional locking overhead when using a single thread or if the underlying sockets already provide thread-safety.

Tue, 14 May 2013 21:40:02 GMT

You are right, free_descriptor_state does not free memory, thus my initial statement that segfault can occur in mutex::scoped_lock dtor is incorrect. However, segfault does happen, although in slightly different place.

in epoll_reactor::start_op you can see following code:

217:  mutex::scoped_lock descriptor_lock(descriptor_data->mutex_);
218:
219:  if (descriptor_data->shutdown_)
220:  {
221:    post_immediate_completion(op);
222:    return;
223:  }

If thread 1 executes epoll_reactor::deregister_internal_descriptor quoted in the begining, while thread 2 executes epoll_reactor::start_op above, thread 2 will segfaults on line 219 if thread 1 completes line 367 (descriptor_data = 0) before thread 2 starts executing line 219. That was actually the problem I have initially ran into. Sorry for confusion, I should have initially described the exact problem I had.

Patch that I have attached on May 1st covers that.

While I completely agree with "It would be unfortunate if applications had to pay for additional locking overhead when using a single thread or if the underlying sockets already provide thread-safety". I just like to point out that mutexes are already in asio code, my patch neither introduce any new locks nor makes locked section longer.

status changed; resolution set

chris_kohlhoff — Fri, 24 May 2013 02:46:04 GMT

status new → closed
resolution → invalid

As you noted, your program violates the documented thread-safety requirements. The current implementation is not really relevant, and it could well change in the future.