Subject: Re: [boost] [Thread][Release] Boost.Thread and 1.45 release
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-10-29 02:52:49
"vicente.botet" <vicente.botet_at_[hidden]> writes:
> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
>> I've fixed all the outstanding "showstopper" bugs in boost.thread on
>> trunk (including the thread interruption issue, #2330),
> I have take a look at the modification associated to this ticket #2330
> thread::interrupt() can be lost if condition_variable::wait() in
> progress and I don't reach to understand why do you need to have an
> internal mutex on condition_variable. The associated patch don't
> modifies this point. The resolution don't states nothing more than the
> ticket has been solved but no how. Please could you explain this
> addition? Is this related to another ticket?
The patch attached to the ticket is incomplete. There is no requirement
that the same mutex is used with the same condition variable instance
for every wait. Therefore, if a thread waits with one mutex, wakes,
destroys the mutex and then waits with another then there is a race
condition with another thread that tries to interrupt it --- the
interrupting thread might try and lock a just-destroyed mutex.
The internal mutex is necessary to eliminate this race condition. This
mutex could be global, but that would introduce a point of contention
between all cond vars.
> This will make condition_variable and condition_variable_any almost
> equivalent. What will be the adavantage to use condition_variable
> respect to condition_variable_any?
The only difference now is that condition_variable_any will accept any
type of mutex in the wait functions. There is no difference between
them in terms of performance.
-- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976