From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-10-18 10:50:09
At 03:02 PM 10/17/2002, David Abrahams wrote:
>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.
The above definition seems to describe the particular form of deadlock
known as "deadly embrace".
General deadlock might be described as "Deadlock is an execution state
where at least one thread is blocked waiting for an action which can never
I guess that one thread being deadlocked doesn't mean the program as a
whole is deadlocked (if the program doesn't require the blocked thread to
ever become active again.) OTOH, if the thread is required to become
active for correct operation, the whole program could be said to be
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk