Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-07-26 05:25:23

Gaetano Mendola <mendola_at_[hidden]> writes:

> On 07/19/2010 03:35 PM, Beman Dawes wrote:
>> It will be Wednesday before I can start pulling the 1.44 beta
>> together.  In the meantime, does anyone have any serious issues we
>> need to tackle before the beta?
>
> Ticket 2330 (https://svn.boost.org/trac/boost/ticket/2330) has a
> proposed patch to solve a showstopper issue related to interrupt
> threads, waiting on same condition, not working. The issue is
> there at least since 1.41. Anthony Williams stated that the patch
> isn't sufficient but at same time he didn't specify why. That patch
> applied proved to solve the problem I'm experiencing in my application
> and on the submitter's patch one.

The patch substitutes one race condition for other problems. If the patch is
applied, one race condition is this:

1. Thread A calls wait()
2. Thread A sets the mutex and condvar in the interruption checker
3. Thread A calls pthread_cond_wait
4. Thread B calls interrupt() on thread A
5. Thread B gets the mutex and condvar for thread A
6. Thread C notifies thread A
7. Thread A wakes from the wait
8. Thread A DESTROYS THE MUTEX AND CONDVAR AS NO LONGER NEEDED
9. Thread B TRIES TO LOCK THE MUTEX AND NOTIFY THE CONDVAR => UNDEFINED BEHAVIOUR

Also there is a potential for deadlock:

1. Thread A locks mutex M
2. Thread A calls wait with a lock on mutex M
3. Thread A sets the mutex and condvar in the interruption checker
4. Thread A calls pthread_cond_wait, which unlocks M
5. Thread B locks mutex M
6. Thread B calls interrupt() on thread A
7. Thread B gets the mutex (which is M) and condvar for thread A
8. Thread B tries to lock the mutex M => deadlock with itself

This deadlock can of course also occur with other threads holding the
mutex, if thread B holds a mutex the other thread needs

I have thought about this problem lots, and decided that you cannot
safely interrupt a condition variable wait on POSIX unless you have a
mutex tied directly to each condition variable (as with
condition_variable_any). I'm therefore not sure how to approach this ---
either every boost::condition_variable has an extra pthread_mutex_t
inside it, or interruption is limited to waits on
boost::condition_variable_any.

Anthony
-- 
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