Re: [boost] More Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-18 07:44:59

"William Kempf" <williamkempf_at_[hidden]> writes:

> >From: David Abrahams <dave_at_[hidden]>

> > > > Well, sort of. Isn't deadlock supposed to be when two threads are
> > > > waiting on one another to finish with some resource before proceeding?
> > > > Yes, that's how definitions.html specifies it.
> 
> I think maybe the definition needs some tweaking.  A deadlock occurs
> when a thread waits on a resource that it can never acquire.  

Well, OK, that's a different definition, and takes us away from the
previous meaning of "deadly embrace".

> This case, where a thread simply never releases the resource, most
> certainly can result in deadlock.

Yes. There's a difference between "can" and "does".

> > > > I think what happens if you fail to unlock a mutex is that the
> > > > resource becomes permanently unavailable**, which is rather different,
> > > > though the behavior may appear to be similar.
> 
> In what ways is this case different?  Even disregarding the effect?

Because for example all threads which use the mutex may decide to exit
without locking it again.

> > > > **to other threads only, in the case of a recursive locking strategy
> > >
> > > I don't think so. If your thread has destructed then it can not be
> > > re-created and therefore you can not ( from anywhere in your process )
> > > recover the leaked resource.
> >
> >Right, so how is that different from saying, "the resource (mutex)
> >becomes permanently unavailable to other threads than the one which
> >locked the mutex"?
> >
> > > 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.
> 
> Did you mean precisely this?

Don't know what you mean by "this", but I meant precisely what I said.

> If so, that points out that the sentence should have read "The
> result is likely deadlock.", rather than the certainty... 

That could certainly be one outcome, but I think it's much more likely
that one thread hangs waiting for another thread to release the mutex
(your new definition of deadlock) than that two threads wait on one
another (or one waits on itself in the degenerate case) which is what
our current definition says. It depends on the system of course.

> but I think maybe you didn't mean precisely what was written here,
> since it's a different take on this then what you've made
> previously.

I don't know what you're getting at.

> > > - recursive mutex or not.
> >
> >Since this can't be described in terms of our definition of deadlock,
> >I'm trying to describe which threads will block forever when trying to
> >lock it. Whether it's recursive or not affects which threads will
> >block forever when trying to lock the mutex.
> 
> How so?

If a thread leaks a recursive mutex, it has a lock on that mutex, and
it can "re-lock" the mutex as many times as it likes without
blocking. So the leaking thread itself can't block forever waiting for
the mutex.

> >OK, fine. This should show up in the rationale, then.
> 
> There's also the fact that recursive_mutexes have several negative
> qualities making them the less preferred types.  And yes, we need
> vastly expanded rationale for everything.  That's something I'm
> working, and comments like these will certainly help.

Definitely. Without that rationale, I would tend to opt for the
recursive_mutex first every time.

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