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.
> > > 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
-- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk