Boost logo

Boost :

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] *
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX

Boost list run by bdawes at, gregod at, cpdaniel at, john at