Boost logo

Boost Users :

Subject: Re: [Boost-users] thread_group::interrupt_all is not reliable
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-12-01 11:43:34

Stonewall Ballard wrote:
> On Dec 1, 2009, at 9:50 AM, Peter Dimov wrote:
>> I can't read the boost.thread code well enough to be able to
>> diagnose the problem, but from a cursory look, it looks possible to
>> me that condition_variable::wait may perform its interruption check,
>> be preempted, the interrupt can proceed with setting
>> interrupt_requested and doing a broadcast, and then
>> condition_variable::wait to block on its pthread_cond_wait.
> I've found that all the threads are waiting on the condition variable
> at the time that I interrupt them, so that scenario doesn't seem to
> apply.

They are before interrupt_all is issued, but then, as you yourself write:

> I think that what's actually happening here is that 16 threads are
> waiting on the same condition, then they're individually interrupted
> (using the above code). Each interrupt wakes all the threads waiting
> on the condition, where all but one thread locks the mutex, see that
> it's not interrupted, then unlocks the mutex and waits.

they are getting interrupted and awakened one by one, the end result being
that condition_variable::wait and thread::interrupt are being called in

> The actual interrupt code in pthread/thread.cpp is:
> As you can see, each thread has a mutex protecting its internal
> state, and the interrupter locks that mutex before setting
> interrupt_requested to true. I think that this precludes a race
> condition there.

It doesn't.

    inline void condition_variable::wait(unique_lock<mutex>& m)
        detail::interruption_checker check_for_interruption(&cond);

        // thread::interrupt is executed here


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at