thread_group::interrupt_all() is unreliable

[stoney@…]

In boost 1_41_0, thread_group::interrupt_all() occasionally fails to interrupt some threads due to a race condition when the threads are waiting on a condition_variable. The solution seems to be to have the interrupter lock the condition_variable's mutex before calling thread::interrupt(). While the fundamental problem is in thread::interrupt(), thread_group::interrupt_all() is a good way to expose the problem, since it happens only when multiple threads waiting on the same condition_variable are being interrupted in quick succession.

A workaround is to have the object owning the condition_variable lock the associated mutex before calling thread_group::interrupt_all(). The attached example demonstrates both the problem and the workaround.

[stoney@…]

XCode project with 1 source file that demonstrates the thread_group::interrupt_all() failure

[Paul Pogonyshev <pogonyshev@…>]

See also ticket:2330 (don't seem to be able to mark as duplicate here).

This is not merely a problem. This is a showstopper, because it renders interrupt_all() worse than not present: unless you know of this workaround, you can introduce a bug into your problem that is very close to track down and can lead to data loss (full lockdown).

[viboes]

See my comment on #3960 condition_variable::timed_wait() cannot be interrupted.

[Anthony Williams]

Duplicate of 2330