Re: [boost] More Threads Review

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-18 09:29:09

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

> From: "David Abrahams" <dave_at_[hidden]>
> > "William Kempf" <williamkempf_at_[hidden]> writes:
> > >
> > > 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".
> 
> It's a better definition, since a thread can "self deadlock" but the current
> given definition would obviously make that impossible.  

Actually, "self-deadlock" is covered by the current definition.

> I think the definition we gave is simply not complete enough, and
> not that we've misused the term elsewhere in the document.

OK.

> > > 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".
> 
> Yep.  I pointed that out below as well.  We'll have to clean this up a bit.
> 
> Note, however, that the chances are VERY high you'll cause deadlock.  

By your new definition, yes.

> The only time you won't is when no other thread is currently
> waiting, no other thread will wait in the future, and the thread
> that leaked either will not wait in the future or the mutex is
> recursive.  In practice it's going to be highly unlikely that any of
> these cases occur, much less all of them.

I think if you change from "will cause deadlock" to "is likely to
cause deadlock" AND you change the definition of deadlock, you'll be
OK.

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