Re: [PATCH] Robust and Real-time Mutexes in NPTL

On Wed, Jul 02, 2003 at 01:45:24PM -0700, Perez-Gonzalez, Inaky wrote:
> > So, basically one would need to make a list of all locks
> > involved and assign an 'ordering' to them.  If thread '1'
> > locks X and then locks Y, then we could "define" that X < Y.
> > When later another thread first locks Y and then X, we notice
> > that it is no longer possible to define an ording for the
> > mutexes and barf.
> 
> We do this already; it is done at the kernel level; it has
> to change a wee bit (to allow enabling/disabling it) but
> basically is that: when you are about to block waiting for
> a lock, the ownership list is walked, the owner of the lock
> you are waiting for; if that owner is waiting, the owner of
> the lock he is waiting for, and so on, until the owner is
> not waiting for any locks (green light) or it points back 
> to you--deadlock.

That sounds like you describe the detection of a *normal*
deadlock that is about to happen.

My proposal is to detect a *possible* dead-lock that
is not actually dead-locking at that moment.  For example:

Thread1:

  lock A
  lock B
  unlock B
  unlock A

And AFTER all of the above has happened, the application
continues (5 minutes later, say) with:

Thread2:

  lock B
  lock A  <-- core dump (possible dead-lock).

The reason being that if the above happens, then
you can assume that theoretically it would have been
possible that it went like this:

Thread1: lock A
Thread2: lock B
Thread1: wait for B
Thread2: wait for A, deadlock.

but, in practise it can happen that this only very
sometimes really deadlocks - and certainly will be
hard to reproduce, and this hard to debug, in many
cases.

-- 
Carlo Wood <[email protected]>