Re: [boost] Re: More Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 15:37:21

Jonathan Biggar <jon_at_[hidden]> writes:

> David Abrahams wrote:
> > > The effect is deadlock
> > 
> > It's not deadlock according to our definition of deadlock:
> > 
> >     "Deadlock is an execution state where for some set of threads,
> >   each thread in the set is blocked waiting for some action by one of
> >   the other threads in the set."
> > 
> > You can't possibly interpret that to cover the case where no thread ever
> > tries to lock the mutex again after the lock is leaked.
> 
> It is the degenerative case where the cardinality of the thread set is
> one, i.e. the thread is blocked waiting for an action the thread itself
> has not yet performed.  In this case, unlocking the mutex, which it
> didn't do due to the exception.

It still doesn't look like deadlock in general.

  a. If you have a recursive mutex, the case above doesn't occur

  b. Any number of other threads can hang waiting on the leaked mutex
  lock as long as the leaker doesn't wait on an action by one of those
  threads, and you still don't have a deadlock by our definition.

I don't see why we have to try to squeeze this bad effect to fit the
term "deadlock". It's something else; let's call a leak a leak.

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html