Boost C++ Libraries: Ticket #4978: Deadlock on interrupt() all threads if they are in wait()

attachment set

d.schneider@… — Mon, 13 Dec 2010 14:54:19 GMT

attachment → thread.cpp

Example code

version changed

moraleda@… — Tue, 01 Mar 2011 01:39:24 GMT

version Boost 1.45.0 → Boost 1.46.0

I am seeing this bug as well. The bug is still present in 1.46. To work around it, I have reordered the locks inside thread::interrupt(), so they are acquired in the same order as in condition_variable::wait() I am not submitting a patch because this does not seem like a clean solution since it involves acquiring the cond_mutex even if local_thread_info->current_cond is false.

himmes@… — Tue, 01 Mar 2011 18:14:46 GMT

We see that problem under MacosX with 1.45.0 as well.

moraleda@… — Wed, 02 Mar 2011 20:03:08 GMT

Replying to moraleda@…:

To work around it, I have reordered the locks inside thread::interrupt(), so they are acquired in the same order as in condition_variable::wait()

My proposed work around does not actually work. The reason is that cond_mutex is mutable and could be changed by another thread if data_mutex is not locked. Thus changing the order of the lock could (and does) result in a segmentation fault. I don't see a trivial fix, so I am reverting to an earlier version of boost thread until this problem is fixed.

attachment set

kosse@… — Fri, 04 Mar 2011 08:17:27 GMT

attachment → deadlock.patch

Experimental fix

kosse@… — Fri, 04 Mar 2011 08:19:49 GMT

I have attached an experimental patch. It solves the problem by reducing the scope of the interruption_checker in the wait and timed_wait functions of the condition_variable(_any).

jochen.seidel@… — Fri, 04 Mar 2011 14:58:29 GMT

Replying to kosse@…:

I have attached an experimental patch. It solves the problem by reducing the scope of the interruption_checker in the wait and timed_wait functions of the condition_variable(_any).

I ran into this issue as well. Your supplied patch fixed the problem - thanks!

status changed; resolution set

Anthony Williams — Fri, 04 Mar 2011 15:49:22 GMT

status new → closed
resolution → fixed

Thank you for the patch. This should indeed fix the problem --- the interruption_point() call needs to happen after the interruption_checker destructor.

Patch committed to trunk, revision 69547

anonymous — Tue, 08 Mar 2011 14:04:18 GMT

Will this bug be fixed in 1.46.1 or do we have to wait until 1.47?

adam — Thu, 28 Jul 2011 09:32:17 GMT

We just encountered this issue, for anyone else coming across this ticket - the deadlock is still present in 1.46.1 but fixed in 1.47.

anonymous — Fri, 16 Mar 2012 19:04:58 GMT

Found this in 1.43 too. Sadly the patch is on a version that is very different from 1.43, going to have to figure out when we can upgrade to 1.47.

anonymous — Thu, 09 Jan 2014 23:25:05 GMT

Same bug still present ( I assume that GCC headers comes from boost, so this one is related to "#include <condition_variable>" when compiling with -std=c++11 flag).. It causing me deadlock in a thread pool..

If anyone still have the same problem a temporary fix is to use "condition_variable_any" instead. the "any" version seems to work (I still see no reason to maintain a specialized version just for unique_lock... over engineering?)

I'd liked to post the link the the discussion on Github, but spam filters blocked it u.u